Introduction

This document was written to give administrators as well as some developers a useful guide to the underlying setting and mechanism of InfoGlue. Hopefully the information herein will help clarify how to set up some aspects of InfoGlue and function as a reference document to all settings available in the system. Whatever the use, I hope the information is valuable and easy to understand.

The document will not include information about pure user aspects or functional development aspects as there are other documents that specialize in these matters. The aim is to give the administrator the best reference document as possible.

Feedback

This document is always a work in progress so mail any suggestions to bogeblad@yahoo.com and I will try to improve it as the platform evolves.

General concepts

What is InfoGlue

InfoGlue is a Content Management System. Content Management is very much another word for how to manage a company’s or organization’s information internally and externally. As content management is such a broad term we often say InfoGlue is a Web Content Management System. That is – InfoGlue helps organizations manage their information mainly targeted for the Web both internally, in intranets etc, and externally in public websites and extranets.

What parts are there in InfoGlue

InfoGlue is a pure Java platform. It is completely database driven which means both the management tool and the public sites are using information from a database. The platform consists of several different applications but from a users perspective the two important ones are the administrative tool and the different delivery engines.

The administrative tools are discussed in detail in the InfoGlue User Manual and are where you manage all aspects of your site. The delivery engines are specialized in presenting sites to users based on the data managed by the tools. By default InfoGlue installs 3 delivery engines. The first is the working version which presents the working version of the site. There is also a version called staging site which shows the site in a preview mode so the publisher can check that the site will look good after publication. The last delivery engine is the one that shows the live site to visitors. This simple sketch shows how a simple setup could look:

Installation

The InfoGlue platform is build on top of standard components and are therefore both easy to maintain and easy to upgrade. This reference will take you through the process of installing it for the first time. This reference is written for Windows and Linux-based systems. If you run a different OS the steps should be the same but some minor details may differ.

Step 1: Installing Java
As the platform is written purely in Java you need the Java SDK installed. InfoGlue has from version 2.4.5 taken a step up and now only supports Java 5 (1.5.x) or later. Since Java 6 is still very young we have not started recommending it although many installations run InfoGlue on it allready. The software is collected on www.java.sun.com. When you got it just install the software according to Sun’s installations instructions. After installation complete it by adding the following environment variables to the system:

SET JAVA_HOME={InstallationPath} (for example c:\j2sdk1.5.5_05 ) PATH=%PATH%;{InstallationPath}\bin (for example c:\j2sdk1.5.5_05\bin )

On windows, this is done by right-clicking on the My Computer-icon and selecting Properties. Then choose the tab Advanced and then Environment variables. In that dialog these settings are made. If you know how you can also make them at the command-prompt. To verify that the installation worked, start a new command prompt and type “java –version”. The result should be something like this:

java version "1.5.0_05" Java(TM) Runtime Environment, Standard Edition Java HotSpot(TM) Client VM (build 1.5.0_05-b06, mixed mode)

We also strongly recommend that you set up some environment parameters:

SET JAVA_OPTS=-XX:MaxPermSize=256m –Xms512M –Xmx512M -XX:NewRatio=4

SET CATALINA_OPTS=-XX:MaxPermSize=256m –Xms512M -Xmx512M -XX:NewRatio=4

The same environment-variables should be set up on Linux (export them as usual vars).

Step 2: Installing Apache Tomcat
The application has to have a servlet 2.3 compatible environment to run in and InfoGlue is known to run on several although the installer only supports Apache Tomcat 5.x or above. Recommended is Tomcat 5.5 or above. This software is of course free and can be found at http://tomcat.apache.org. When you have the right software just install it as instructed. To check that the installation was successful you might want to start tomcat from the start-menu and then browse to http://localhost:8080. There you should see a tomcat information screen. After this check please stop tomcat and proceed to step 3.

Step 3: Installing MySQL
All information in the InfoGlue platform is stored in a database. This database could be almost any JDBC-2 compliant database and the installer default supports MySQL, SQL-Server, DB2 and Oracle. This tutorial will instruct how to install the fast, competent and free MySQL database. You can fetch it from www.mysql.com. InfoGlue supports ver. 3.23 or later but strongly suggests version 5.0 or above as a number of limitations has been removed in that version. Install the database as instructed by the MySQL documentation. If you want to use large attachments on your sites like large images or movies you must follow the instructions on http://www.mysql.com/doc/en/Packet_too_large.html. The standard limit is about 1Mb so you will probably want to do that.

Step 4: Installing InfoGlue

Normal way

Time has come to install the InfoGlue platform itself. The installer comes in a zip-file which you just unpack with your favorite unzip-program. In the installation directory there is a visual installer you start by running the install.bat(windows) / install.sh (Linux) file. If you prefer a command based installation run installcmd.bat (Windows) / installcmd.sh (Linux) instead. The installer will try to guide you as much as possible and if you move the mouse over the labels in the visual installer more help will be shown as tool tips. If you want to run it from Unix/Linux-systems you have to set the rights on the new directory so it can be executed. This is done by “chmod 777 * -Rf” in the newly unzipped directory. Below is a small sequence for Linux-users and it assumes you are located in the directory where you downloaded InfoglueInstaller2.x.xFinal.zip:

unzip "InfoglueInstaller2.x.xFinal.zip"

chmod 777 "InfoglueInstaller" -R

cd "InfoglueInstaller"

./installcmd.sh

Silent option

If you want to you can specify all setting for the installer in an xml file named installconf.xml and run the installer in silent mode. This is convenient sometimes for a hosted environment or if you wish to automate the installation. Just modify the existing config example file and run InfoGlue with silent option.

Example windows: “infogluecmd.bat silent”

Example linux/unix: “./installcms silent”

Upgrading older versions of InfoGlue

The installer can also upgrade existing versions of InfoGlue including updating the database model if needed. Up to now InfoGlue can upgrade versions so far back as 1.0 and we hope to keep it that way in the future. That way upgrades should be pretty easy. When upgrading from 1.3.2 or earlier there may be some problems with access rights, packet structure and other backward compability issues which can be resolved but you should know about. Since 2.0 InfoGlue has settled much more into a more modern setup.
Detailed descriptions of the fields in the installer / upgrader:

Database dialog:

Database type: The database brand you wish to install or upgrade InfoGlue on. Valid are "MySQL", "SQL Server", “DB2” and “Oracle”.

Database name: The name of the InfoGlue database – either an existing one you wish to upgrade or the one you wish to create.

Database suffix: This field gives you the option to add a suffix to the database name so you can have more than one InfoGlue installation in the same database. Used primarily in hosting services.

Database server: The hostname of the database server on which the database is located. Can be an IP or a hostname.

Database port: The port for the database server if different from default.

Database instance: Use this for SQLServer setups where you have several instances running.

InfoGlue username: The username InfoGlue is to use for connecting to the database. This username is not related to user’s logins.

InfoGlue password: The password InfoGlue is to use for connecting to the database. This password is not related to user’s logins.

Create database: Do you wish to install a new InfoGlue database? If you already have an InfoGlue installation and wish to keep the data you don't want to. This feature is only available for MySQL and SQLServer. If you are upgrading an old install don’t select this.

Create tables and initial data: Do you wish to InfoGlue to fill the database with the needed tables etc. If you don’t want to script the creation of the database yourself you should choose this. If you are upgrading an old install don’t select this.

Create example sites: This installs a couple of example sites for you to look at. If you are upgrading an old install don’t select this.

Upgrade to utf-8: Use this option if you have tried to upgrade and international characters gets messed up. It fixes a problem in the 1.2-version. DO NOT USE AFTER 1.2.

DBA name: The root (or similar) username to the database. InfoGlue needs it if it’s to create the database in a new install.

DBA password: The root (or similar) password to the database. InfoGlue needs it to be able to create the database.

Server dialog:

Host Name: The hostname or IP-address of the application server you are installing InfoGlue on. If you want people to access your site from other computers this is important to set correctly.

Port number: The port number tomcat operates on.

Application suffix: The suffix will be added to the name of the InfoGlue applications. This feature is mostly used in shared environments like hosting services. You can leave it out if this is a one-client installation.

Tomcat HOME: Point out the home directory of your tomcat installation. Often something like c:\Program Files\Apache Group\Tomcat 4.1

Tomcat VERSION: We now support both tomcat 4.x and 5.x but it is important you state which version it is as they have organized their files a bit different.

InfoGlue HOME: Point out the home directory of your InfoGlue directory. As InfoGlue will create a couple of applications/subdirectories you are wise to create a common InfoGlue directory somewhere on the disc which you then supply.

Enable JSR 168 support: This sets InfoGlue up support the JSR-168 portlet specification. Choosing this forces install under tomcat webapps.

Applications to install: InfoGlue consists of several applications and two are mandatory. You are also able to select if you wish to install a preview-deliver and a live-deliver. The preview-deliver is used for preview at publication and the live site shows only published data and are aimed to be the deliver used for the public. Both options are recommended.

SMTP Host: Your email server used for outgoing mail.

Super user: The account name of the super user you want to create.

Password: What password the super user should have.

After installation you should start Tomcat again and open the address stated by the installation program. The default login name is “administrator” and the password is “changeit”. If images does not show and you are running Linux you probably have to chmod the directory digitalAssets and logs under each installer application so the applications are allowed to create files there.

WARNING: InfoGlue puts the root account in the cms.properties under the cms webapp. This account is used when security settings have been set up invalid or you must override something without having the rights as an administrator. Be aware to use a good password and username here as it will be a security risk if you don’t. To secure the application even more you can remove the username and password altogether.

Now you are ready to go!! Good luck in building you websites.

Alternative deploy configuration

Instead of using the installer some people and projects prefer to set up a deployment environment which let’s them redeploy a configuration easily with just an ant-task. This is a recommended way when working with a development server which you want to be able to update easily and we also use this way for some live installations as the approach let’s us get the newest InfoGlue versions automatically with one command. One should however know how CVS works and only fetch the latest stable InfoGlue versions if it’s a production environment.

I thought we should be nice and describe a simple example setup.

First we create a Build-folder:

cd /root (can be anywhere – this is just an example)

mkdir BuildProject

mkdir software

Download Apache Ant

cd software

wget http://www.infoglue.org/downloads/apache-ant-1.6.5-bin.tar (or get it from the official apache)

tar -xvf apache-ant-1.6.5-bin.tar

cd ../BuildProject

Fetch the latest version of InfoGlue:

cvs -d :pserver:anonymous@www.infoglue.org:2401/home/cvsroot checkout infoglue

or fetch a tagged version

cvs -d :pserver:anonymous@www.infoglue.org:2401/home/cvsroot checkout infoglue241final infoglue

Create redeployAll.sh in BuildProject containing:

/etc/init.d/tomcat stop

rm /usr/local/tomcat5.5/logs/* -f

cd infoglue

#Enable this if you wish to have always the latest development version of InfoGlue to be fetched.

#/root/software/apache-ant-1.6.5/bin/ant --noconfig fetchInfoGlue

/root/software/apache-ant-1.6.5/bin/ant --noconfig deploy

/root/software/apache-ant-1.6.5/bin/ant --noconfig deploy-pluto

Chmod it:

chmod 755 redeployAll.sh
Now create and edit infoglue/build.properties

Set all paths and database settings so it suits your needs. Here is a template with the most used parameters:

rm infoglue/build.properties

vi infoglue/build.properties

Infoglue/build.properties

# $Id: build.properties,v 1.27 2005/11/20 20:59:46 mattias Exp $

###############################################################################

project.version=2.4.1

#build.compiler=jikes

# deployment directories for each version of the InfoGlue webapp

deploy.dir.cms=/usr/local/tomcat5.5/webapps/infoglueCMS

deploy.dir.working=/usr/local/tomcat5.5/webapps/infoglueDeliverWorking

deploy.dir.preview=/usr/local/tomcat5.5/webapps/infoglueDeliverPreview

deploy.dir.live=/usr/local/tomcat5.5/webapps/infoglueDeliverLive

# database

#Oracle

database.driver.class=com.mysql.jdbc.Driver

database.driver.engine=mysql

database.url=jdbc:mysql://localhost/infoglue?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8

database.user=infoglue

database.password=xxxxxxx

database.minLimit=5

database.maxLimit=200

database.maxConnections=200

database.mapping=mapping.xml

database.encoding=UTF-8

database.use.unicode=true

# Hibernate

hibernate.dialect=net.sf.hibernate.dialect.MySQLDialect

hibernate.show_sql=false

masterServer=

slaveServer=

# Which mode does the engine run in... 0=working(first preview), 2=publish(staging preview), 3=published(live)

operatingMode.cms=0

operatingMode.working=0

operatingMode.preview=2

operatingMode.live=3

# portlet

enablePortal=true

actionDispatcher=org.infoglue.deliver.portal.dispatcher.PortalServletDispatcher

portletBase=/usr/local/tomcat5.5/webapps/

portletBase.working=/usr/local/tomcat5.5/webapps/

portletBase.preview=/usr/local/tomcat5.5/webapps/

portletBase.live=/usr/local/tomcat5.5/webapps/

deploy.dir.shared=/usr/local/tomcat5.5/shared/

# web-specific settings, user to locate images, etc.

externalWebServerAddress=

webServerAddress=http://xxx.xxx.xx

liveWebServerAddress= http://xxx.xxx.xx

context.root.cms=infoglueCMS

context.root.working=infoglueDeliverWorking

context.root.preview=infoglueDeliverPreview

context.root.live=infoglueDeliverLive

#digitalAssetPath=/usr/local/tomcat5.5/webapps/digitalAssets

#requestArgumentDelimiter=&

URIEncoding=ISO-8859-1

workflowEncoding=UTF-8

#errorUrl=http://localhost:8080/error.html

errorUrl=/error.jsp

errorBusyUrl=/errorBusy.jsp

enableNiceURI=true

niceURIEncoding=UTF-8

niceURIAttributeName=NiceURIName

#Cache settings

useSelectivePageCacheUpdate=true

cachePath=/tmp

compressPageCache=true

siteNodesToRecacheOnPublishing=100470,102310,102330,100081,100190

pathsToRecacheOnPublishing=/,/omuniversitetet/,/forskning/,/samverkan/

recachePublishingMethod=requestAndMetaInfoCentric

recacheUrl=http://localhost/ViewPage.action

# default tree

tree=html

#settings for how the content tool should work

showContentVersionFirst=true

#settings for how the structure tool should work

showComponentsFirst=true

#Setting for if content types can be protected

protectContentTypes=false

#Setting for if categories can be protected

protectCategories=false

# Protect workflows

protectWorkflows=false

#Setting for which HTMLEditor to use FCKEditor | HTMLArea

wysiwygEditor=FCKEditor

#SET THIS TO TRUE IF YOU ARE RUNNING ORACLE OR DB2

useShortTableNames=false

# Show all workflows or only the one you owns

showAllWorkflows=false

# edition pagination

edition.pageSize=10

# AutoUpdate Settings

# ( Should point to masterserver, which provide a mirror list later

# For now, point up2dateUrl directly to a xml updates list )

up2dateUrl=http://www.infoglue.org/infoglueDeliver/ViewPage.action?siteNodeId=23

# security settings - basic

#loginUrl=Login.action

loginUrl=https://localhost:8080/infoglueDeliverWorking/Login.action

invalidLoginUrl=Login!invalidLogin.action

authenticatorClass=org.infoglue.cms.security.InfoGlueBasicAuthenticationModule

authorizerClass=org.infoglue.cms.security.InfoGlueBasicAuthorizationModule

serverName=localhost:8080

authConstraint=cmsUser

extraParametersFile=InfoGlueAuthorizationParameters.properties

casValidateUrl=

casServiceUrl=

# mail

mail.smtp.host=smtp.xxx.xx

mail.smtp.auth=false

mail.smtp.user=

mail.smtp.password=

mail.contentType=text/html

systemEmailSender=mattias.bogeblad@modul1.se

warningEmailReceiver=mattias.bogeblad@modul1.se

# Sets up a superuser

administratorUserName=root

administratorPassword=xxxxxx

administratorEmail=mattias.bogeblad@modul1.se

When save run redeployAll.sh i /root/BuildProject

./redeployAll.sh

The result shall be BUILD SUCCESSFUL.

Adding Apache HTTP-Server as a front-end

Many linux/unix-servers have Apache HTTP-server installed by default and it may even be used by several previous projects. If so there are many InfoGlue-installations which utilize the web server as a front-end to Apache Tomcat. Even though this is not an InfoGlue-specific task we have decided to include a small and simple how-to here.

First make sure Apache HTTP-server is installed. If you don’t know how you should start on www.apache.org before continuing.

We will use the Apache mod_jk-module for connecting Apache and Tomcat. Download and install from http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/ or download and compile yourself.

When installed you configure it by adding this or similar last to the httpd.conf (often in /etc/httpd/conf) or in an included file:

# Mod_jk settings

AllowEncodedSlashes On

JkWorkersFile "/usr/local/tomcat5.5/conf/workers.properties"

JkLogFile "/usr/local/tomcat5.5/logs/mod_jk.log"

JkLogLevel error

JkMount /infoglueCMS default

JkMount /infoglueCMS/* default

JkMount /infoglueDeliverWorking default

JkMount /infoglueDeliverWorking/* default

JkMount /infoglueDeliverPreview default

JkMount /infoglueDeliverPreview/* default

JkMount /infoglueDeliverLive default

JkMount /infoglueDeliverLive/* default

# Use SetEnvIf if you want to let apache take care of all digitalAsset calls so Tomcat only get app-calls. Improves performance quite a bit actually. Use only for the live instances.

SetEnvIf Request_URI "/digitalAssets/*" no-jk

# Now /home will goes to the dir below - Use only for the live instances.

Alias /digitalAssets /usr/local/tomcat5.5/webapps/infoglueDeliverLive/digitalAssets

JkMount /* default

# End of mod_jk settings

Then create workers.properties in the dir pointed out in the conf (in this case /usr/local/tomcat5.5) with the following content:

workers.tomcat_home=/usr/local/tomcat5.5

workers.java_home=/usr/java/jdk1.5.0_04

ps=/

worker.list=default

worker.default.port=8009

worker.default.host=localhost

worker.default.type=ajp13

worker.default.lbfactor=1

Then restart Apache HTTP-server and make sure Tomcat is running. Then call the server through apache. Usually that means calling the same address but on port 80 instead of 8080.

InfoGlue Configuration

In InfoGlue not much is hard coded. Almost all settings affecting the behaviour of the system can be configured either in the tools or in the properties files on disk.

We have tried to let administrators keep as much as possible of their configurations in the database as that very much eases the upgrade process in the future as well as let’s the users reconfigure and manage the application settings through the management interfaces.

To allow this InfoGlue is coded so it first checks if an application setting exists in database-driven application properties. If not InfoGlue checks in the properties-files on disk and lastly, if not defined there either, it defaults to preset values. The next sections describe these settings.

Application settings

This part describes the settings that can be handled through the management tool. If you wish to have different settings for different servers you can add server nodes in this view as well. Just be sure to call the new nodes what the servers are called (InetAddress) as the names are used when looking for server specific properties. This feature is not used by many but now you know it exists.

InfoGlue fetched any property it needs like this:

Check if there is a server node matching the server running the InfoGlue instance wanting the property/setting. If so InfoGlue gets the application setting in question filled in under that node.

If no value or no server node was found InfoGlue looks at the default application settings and fetches the value for that attribute.

If no value was specified in either local server node or in general application settings InfoGlue fallbacks to the property files on disk. Mainly deliver.properties and cms.properties. It looks for the value there.

If still no property was found a default value is used which is hard coded in the application.

Since InfoGlue 2.3.5 we recommend all app settings to be handled in the management tool with one or two exceptions which should be handled in the property files as they are unique to each deliver-instance.

If you can access the management tool (the blue tab) just press “Application settings”.

Before we head into the detailed properties we would like to point the only field in this screen:

Allowed admin IP-addresses: States the IP-addresses that are allowed to call some admin actions. This is very important as you must allow the cms-server’s IP if you got a distributed environment as the cache update calls are handled like this. If not the cache will not get updated correctly.

To edit the actual properties press the “Edit Properties”-button.

Below is a thorough walkthrough of the sections and fields under the edit properties button.

Cache settings:

These settings all have to do with caching and reaching issues.

Name / description

Enable Page Cache: Enable or disable the page cache possibility globally. You must have a very good reason for setting it to “No” as it has a big performance impact and the cache on pages can be disabled individually instead where needed.

Selective page cache update: Enable or disable if pages should be updated selectively in deliverWorking – do not set to “No” unless you have a special reason.

Expire cache automatically: Enables one to set that the page caches and other caches are thrown away every x millisecond (x defined below). This is not a common setup as it’s quite ineffective and there are better options if such behaviour is needed.

Cache expiration interval: How many milliseconds to wait until refreshing the caches. Only used if Expire cache automatically is set to yes.

Request timeout (in deliverWorking and preview only): If set to a positive value the working/preview deliver will kill off request-threads that take longer than the set value. This is to avoid faulty test templates etc to block/disrupt the system. A value between 30000 and 120000 could be suitable if you have problems with blockage/hangs – otherwise keep empty.

Request timeout(in deliverLive only): If set to a positive value the live deliver will either report or kill off requests that take longer than the set value. This is to avoid stability issues when issues arises. In some situations blocked threads can linger forever. A value between 30000 and 120000 could be suitable if you have problems with blockage/hangs – otherwise keep empty. Very nice to have if you have surrounding systems which are behaving badly like taking to long for example. Whether it kills the thread after the time specified here or just sends a warning mail depends on the next field.

Kill live request after timeout: Decides if the live deliver should kill threads or just warn the sysadmin when threads take to long.

Limit the number of active threads: This feature lets you tell InfoGlue to qeue up threads if to many comes in at once so we limit the synchronization costs. OBS: Use only after you have tested very much in a controlled environment so you know what is best for your site. Not many needs this setting.

Max number of concurrent threads: Lets you state how many threads can be active at once. Only active if you set the previous setting to true. A value of 20 to 40 is not uncommon if used.

Max time for requests before starting sleeping new threads: Lets you specify how long the request must become before InfoGlue should start to limit the incoming active requests. Only active if you set the previous setting to true. A value of 3000 (milliseconds) is not uncommon if used.

Session timeout: How long until a user session are invalidated? Controls

when a user is automatically logged out etc. Set in milliseconds.

Compress page cache: States if the page cache should be compressed before stored in memory. Saves quite a lot of RAM.

Compress page response: States if the resulting pages should be gzip:ed before sent to the visitor. Saves bandwidth and speeds delivery a bit.

A commaseperated list of sitenodes to recache: This is to enable one of the recache strategies to know what to recache after a publication.

Recache method: Can be one of these:

requestCentric (recommended) – before flushing all caches the strategy makes a few requests to specified pages so a lot of data get’s reached. Minimizes the load after a publication.

requestAndMetaInfoCentric - before flushing all caches the strategy makes a few requests to specified pages and indexes all pages meta info so a lot of data get’s reached. Minimizes the load after a publication – a bit slower.

contentCentric - before flushing all caches the strategy indexes some contents. Minimizes the load after a publication – not recommended.

Recache URL: Used by the recache strategies which calls pages. Should point out the ViewPage.action with a full url.

Use IP-security: States if some application actions like UpdateCache and ViewApplicationState should be protected on which IP-addresses the call come from. If set to Yes you must specify the ip-addresses in the field below.

Allowed admin IP-addresses: States the IP-addresses that are allowed to call some admin actions. OBS: This settings are also on the application settings startpage – use them there. Take care in allowing the cms-server to do this as the cache update calls are handled like this. If not cache will not get updated correctly.

Default page cache key: States what parameters should be taken into account when creating or fetching data from the page cache. The complexity of this affects how large the page cache is in memory and how often the page cache holds what the user wants. The default key is:

siteNodeId_languageId_contentId_userAgent_queryString

which means for example which browser the user has affects the hit rate on the cache. If one knows one will not make components which cares of the browser on the server side the page cache key can be shorter which is good. If one need cookies and session parameters can be used in the key.

Default component cache key: States what parameters should be taken into account when creating or fetching data from the component cache (cache containing complete rendered component on a page). The complexity of this affects how large the component cache is in memory and how often the cache holds what the user wants. The default key is:

{pageCacheKey}_componentId_componentSlotName_componentContentId_isInherited

which means here as well for example which browser the user has affects the hit rate on the cache. If one knows one will not make components which cares of the browser on the server side the page cache key can be shorter which is good. If one need cookies and session parameters can be used in the key.

Cache settings: This is a new feature since 2.4.5 which allows you to state individual sizes for each cache. The syntax is for example:

CACHE_CAPACITY_contentVersionCache=10000

CACHE_CAPACITY_componentPropertyCache=5000

CACHE_CAPACITY_contentAttributeCache=50000

This means that the cache called “contentVersionCache” as named in the ViewApplicationState.action-view will use a LRU-algorithm when inserting things in the cache. When the cache capacity we have defined as 10000 above reaches it’s limit it will throw away the item used least recently. This way one can control memory usage quite a bit. Especially the page cache and some caches above can be very large after a while. If you start running without these settings you can check out how much memory is used in ViewApplicationState.action and limit the memory if needed. Remember – less memory caches means worse performance so don’t take it to far.

CMS connection settings:

These settings handles the connection between the deliver-environments and the cms-application. For example so EditOnSight works etc. Most of these settings are set right by the installer in the property-files so we seldom need to modify this. Because of this we have not gone into much details on this.

Name / description

CMS Full Base URL: The full URL to the cms. This is used by the MyDesktop-tool as the return address when invoking workflows from there.

CMS Base URL: The path to the cms. Could be a full url or a relative one to the domain. Used to construct action-urls in structure tool for example to avoid relative urls which might be a problem.

Component editor URL: Points to the action that edits pages (add / remove components etc). Used by the structure tool component editor.

Component renderer action: The component editor action.

Edit On Sight URL: Points out the editor action URL.

Template processor settings:

Simple section – just one setting.

Name / description

Use Freemarker as the default template engine instead of velocity: Tells InfoGlue to use freemarker as the default template engine if not JSP was declared in the component/template. The developer docs explains in details how this works.

Web server settings:

This section let’s you define what addresses meet the user or what paths the applications should put files in. Leave empty most of the time.

Name / description

Web server address: Never use this really except if you know what you are doing. Leaving it blank let’s InfoGlue operate with relative URLs only which is more flexible.

Application base URL: The cms base URL.

Digital asset base URL: What URL the assets are found at. Defaults to the dir under the webapp and is relative the context by default.

Images base URL: The URL to the standard InfoGlue image directory. Leave it empty.

Digital asset path: The file system path to where assets should be stored. Defaults to a folder called digitalAssets under the webapp dir – could be set to a SAN or something.

URL settings:

This section let’s you define how InfoGlue URLs are generated.

Name / description

Enable Nice/Friendly URI: Set to Yes if you want the deliver engine to render url:s like /products/infoglue_cms instead for /ViewPage.action?siteNodeId=7 etc.

Nice/Friendly URI encoding: What encoding should be used if encoding takes place due to i18n-characters.

Nice/Friendly URI attribute: What meta info attribute should be used to generate the URI:s. Can be any page meta info attribute or SiteNode.name which uses the non localized name from the structure three.

Request argument delimiter: Should we use & or & or ; as the argument separator?

Error handling / Thumbnail and encoding settings:

These sections let’s you define error handling, thumbnails and encoding settings.

Name / description

Error page URL: If you want a custom error page you can set that here. When an error occurs the user will be shown the information and the url can be relative or full.

Busy page URL: Not used at the moment.

External thumbnail generator: The full path to image magic you have that installed and want to use it rather than the ordinary Java2D-resizing.

Input character encoding (cms): What input character encoding should we expect? Seldom needed to be changed – only if you experience encoding problems when entering data in InfoGlue’s standard GUI:s.

Input character encoding (deliver): What input character encoding should we expect when data is entered on pages on the site? Important when we use portlets etc and can depend on what encoding the site is written in, how the web server/tomcat is configured etc.

URI-encoding: What encoding should be used when InfoGlue deals with i18n strings when creating url’s inside cms?

Workflow encoding: What input character encoding should be used for the workflow definitions. Defaults to utf-8.

Property forms encoding: Not used at the moment.

Database / Log and Portlet settings:

These sections let’s you define error handling, thumbnails and encoding settings.

Name / description

Use short table names: The value should be “Yes” if you run InfoGlue against a DB/2 or Oracle database. Set by the installer usually but can be set here as well.

Log database transactions: Not used at the moment.

Enable site statistics: Not used at the moment.

Statistics logs path: Not used at the moment.

One statistics log file per day: Not used at the moment.

Statistics logger mode: Not used at the moment.

Enable JSR-168: Controls if you want the possibility to deploy portlets. Should probably always be set to “Yes” as we don’t see any downside to have it enabled even though you don’t use portlets at the moment.

Portlet base: Should point to the tomcat home directory at the moment as Apache Pluto demands this.

Mail settings:

These sections let’s you define the system’s mail settings.

Name / description

SMTP host name: Here you can define the mail server so InfoGlue can send e-mails.

Use SMTP authentication: If the mailserver requires authentication set this to Yes and fill in user name and password below.

User name: The user name for the mail server.

Password: The password for the mail server.

System email sender email: The email address which should be used as sender address.

Surveillance email receiver: The email address to which problems should be reported. OBS: Very important now for debugging situations – a lot of info comes here.

Protection settings and misc settings:

These sections let’s you define protection and miscellaneous settings.

Name / description

Disable image editor: Not used at the moment.

Protect content types: Set to yes if you want to access control what content types users should see. Take care as when you switch to Yes you will have to go through all content types and set rights. If enabled none of the content types are usable by anyone by default.

Protect workflows: Set to yes if you want to access control what workflows users should see. Take care as when you switch to Yes you will have to go through all workflows and set rights. If enabled none of the workflows are visible to anyone by default.

Protect categories: Set to yes if you want to access control what categories users should see. Take care as when you switch to Yes you will have to go through all categories and set rights. If enabled none of the categories are visible to anyone by default.

Allow publication event filter: If set to yes the users are able to notify the publishers in their group about what they have sent to them. More on that feature in the user manual.

Default publication event filter: Sets the default choice for the feature.

Protect working deliver: Set to yes if you want to force login to the working deliver. Usable to avoid people to authorized to peek at the working site.

Protect preview deliver: Set to yes if you want to force login to the preview deliver. Usable to avoid people to authorized to peek at the preview site.

Max rows shown on content search: How many found items should be shown after a search.

Show content version first: When clicking on a content InfoGlue shows the master language version first instead of the content cover. If you don’t want this behavior set this to “No”.

Tree version: Allows you to change the tree implementation. Default the value is “html” but it can be “applet” as well.

Show components first: By default InfoGlue shows the working version of a page when you click on a site node in the structure tool. If you rather want the page cover to be shown set this to “Yes”

Show all workflows: Set to Yes if you want the users to see all workflows even if they are not involved.

Enable edit on sight: No good reason to disable it completely but it’s possible here.

Miscellaneous settings continued:

Name / description

Preview deliver url: Not used at the moment. Has been replaced by how we define things in repository-dns-name (working= etc).

Staging deliver url: Not used at the moment. Has been replaced by how we define things in repository-dns-name (preview= etc).

Internal deliver urls: Here you register all working and preview delivery-engines. These url:s are used when cache messages are broadcasted. Format (index based):

0=http://xxx.xxx.xx/infoglueDeliverWorking

1=http://xxx.xxx.xx/infoglueDeliverPreview

2=http://yyy.yyy.yy/infoglueDeliverWorking

3=http://yyy.yyy.yy/infoglueDeliverPreview

Public deliver urls: Here you register all live delivery-engines. These url:s are used when publication cache messages are broadcasted. Format (index based):

0=http://xxx.xxx.xx/infoglueDeliverLive

1=http://yyy.yyy.yy/infoglueDeliverLive

Edition page size: Allows you to specify how many publications are shown at a time.

Content tree sort: Here you can state how the tree in content tool should be sorted. Normally sorted by content-name but you can state other attributes like id, publishDateTime or other content properties.

Structure tree sort: Here you can state how the tree in structure tool should be sorted. Normally sorted by site node name but you can state other sort-attributes as well. Like for content tree you can use id, publishDateTime and other SiteNode-properties but you can actually also use the site nodes meta info attributes by adding extra: first. This example sort first on pages meta info attribute sortOrder and if not there by name. “extra:sortOrder,name“

Structure tree hidden property: This is a feature in structure tool which allows you to visualize if some pages are hidden on the site. Just state what meta info attribute points this out. For example isHidden if that is the attribute you used.

Misc settings continued:

Name / description

Disable empty urls: Not used at the moment.

Cache update action: Do not change unless you are a developer and have added your own cache update strategy which is very, very uncommon.

Log path: Not used at the moment.

Log transactions: Not used at the moment.

Enable extranet cookies: Do you want the users to be remembered through a cookie between sessions so they do not have to login again and again.

Use alternative language check: Do not change this.

Case sensitive redirects: By default the redirects are not case sensitive.

Use DNS name in URI: Set this to Yes if you want all url:s to be full – opposed to relative which are default.

Extranet cookie timeout: Set the expiration period of the extranet cookie (if enabled).

Webservice base URL: If you build stuff where users can edit things from the site through the IG-webservices you must point out the services here.

Live publication thread class: Can be org.infoglue.deliver.util.SelectiveLivePublicationThread instead of the default and if set to this the live environments are also updated dynamically and selectively. Improves performance but is still in Beta-mode.

Publication thread delay: How long should the system wait until the publication process starts. This is used only when you have a setup where you replicate the database between the working and live servers and the replication can take a minute or two.

Paths to recache in publishing: Enter paths on the live servers that should be called after a publication. To increase performance and delay after a publication.

Disable template debug: If you don’t wish the working deliver to output errors etc in the site you set this to Yes and only look at the logs for debug.

Export format: Since 2.4 InfoGlue’s export and Import system is much more advanced and needs a new format. Only use 1 for old systems.

Misc settings continued:

None of these settings are used at the moment so we will not describe them.

Security settings CMS:

These sections let’s you define how authentication and authorization are handled in the cms. Most of the field names speaks for themselves but more information can be found under the chapter on Authentication and Authorization.

A new thing in 2.4.6 is that one can specify more than one role name as auth constraint for the tools. Just use the “;” as separator and complement with more names. For example one can state the contraint “cmsUser;helpdesk” to specify that users who have the role “cmsUser” and/or “helpdesk” are allowed. This only applies to the cms login of course – not to deliver logins.

Security settings Deliver:

These sections let’s you define how authentication and authorization are handled in the delivery engine (extranet for example). Most of the field names speaks for themselves but more information can be found under the chapter on Authentication and Authorization.

CMS GUI settings:

These sections let’s you define shortcuts etc.

Name / description

Shortcuts: Here you can define application/task shortcuts which will be shown in the myDesktop tool.

The format is xml-based and here is an example:

<?xml version='1.0' encoding='UTF-8'?>

<name>InfoGlue Official homepage</name>

<url>http://www.infoglue.org</url>

</shortcut>

<name>Other tool</name>

<url>http://www.yourtool.com/toolX</url>

</shortcut>

</shortcuts>

Configuration files

All the configuration files are located under WEB-INF/classes under respective webapp, both cms and deliver. There is also a web.xml for each application which contains some settings for filters. The most central files are:

CMS-application is controlled in the cms.properties

Below “infoglueCMS{suffix}/WEB-INF/classes” there are a file called “cms.properties”. It contains all settings for the CMS-application if not defined in the application settings in management tool and the possible setting are listed below:

Cache settings for the component editor environment
Field name	Typical values	Comment
isPageCacheOn	true / false	Allways use true except for debugging purposes or for a completely dynamic site.
expireCacheAutomatically	true / false	false is default.
cacheExpireInterval	1800000	Only set this value if you set expireCacheAutomatically=true – should not be used in cms really
session.timeout	1800	This sets the timeout for the user session in the tools. Defaults to 30 minutes (1800 seconds)
WEB-SPECIFIC SETTINGS (USED TO LOCATE IMAGES ETC)
Field name	Typical values	Comment
webServerAddress	http://localhost:8080	Never use this really except if you know what you are doing.
digitalAssetBaseUrl	infoglueCMS/digitalAssets	Defaults to the dir under the webapp.
imagesBaseUrl	infoglueCMS/images	Only set this value if you set expireCacheAutomatically=true – should not be used in cms really
digitalAssetPath	/usr/local/tomcat/webapps/infoglueCMS/digitalAssets	Defaults to the webapp dir – could be set to a SAN or something.
Thumbnail generation
Field name	Typical values	Comment
externalThumbnailGeneration		Could point to image magic if installed.
Encoding settings
Field name	Typical values	Comment
URIEncoding	UTF-8	Descides in which way the urls in the tools are generated. If you have internation characters in role/user or group names this will be important.
Logging
Field name	Typical values	Comment
logTransactions	true / false	This descides if to log activity or now into the table cmTransactionHistory. Default true.
logDatabaseMessages	true / false	Old setting – not used any more.
logToFile	true / false	false is default – old setting we now uses log4j.
logPath	/tmp/logs/tool.log	Old setting
logLevel	INFO, WARNING, ERROR	Old setting
Preview settings
Field name	Typical values	Comment
previewDeliveryUrl	An url to the working version of InfoGlue.	Used allways except if NiceUri:s are configured with a working-url.
stagingDeliveryUrl	An url to the preview version of InfoGlue.	Used allways except if NiceUri:s are configured with a working-url.
Replication / Syncronization messaging
Field name	Typical values	Comment
internalDeliverUrl.0	An url to the deliver context.	The index starts with 0 but can be any number of additional urls.
internalDeliverUrl.x
Publication settings
Field name	Typical values	Comment
publicDeliverUrl.0	An url to the public deliver context.	The index starts with 0 but can be any number of additional urls.
publicDeliverUrl.x
Cache update settings
Field name	Typical values	Comment
cacheUpdateAction	UpdateCache.action	Allways use this.
Language settings
Field name	Typical values	Comment
0.toolLanguageCode	sv, en, fr	The index first starts with 0 but can have any number of additional languages.
x.toolLanguageCode
Tree settings
Field name	Typical values	Comment
Tree	Applet/html	Sets if the system should use the applet or the html tree.
treemode	Dynamic/static	The default is the new dynamic tree.
content.tree.sort	Id, name etc	The sort order in the tree
structure.tree.sort	Id, name etc	The sort order in the tree
Misc
Field name	Typical values	Comment
showContentVersionFirst	true / false	Decides if to show the master content version directly upon selection of a content.
showComponentsFirst	true / false	Decides if to show the page component view directly upon selection of a sitenode.
protectContentTypes	true/false	Selects if to protect content types or not from visibility to all users.
protectCategories	true/false	Selects if to protect categories or not from visibility to all users.
wysiwygEditor	FCKEditor / HTMLArea	Selects which html-editor to use.
helpUrl		The url the help-button opens.
Search settings
Field name	Typical values	Comment
maxRows	100	How many rows should be shown in search.
Publishing settings
Field name	Typical values	Comment
edition.pageSize	10	How many editions should be visible in the publishing tool.
Database setting
Field name	Typical values	Comment
useShortTableNames	false	SET THIS TO TRUE IF YOU ARE RUNNING ORACLE OR DB2.
masterServer	cms.infoglue.org	Set this value only if you are running in a replicated mysql-environment.
slaveServer	www.infoglue.org	Set this value only if you are running in a replicated mysql-environment.
Mail settings
Field name	Typical values	Comment
mail.smtp.host		The mail server
mail.smtp.auth		If to use authentication
mail.smtp.user		Username if using auth
mail.smtp.password		Password if using auth
systemEmailSender		The system email address, sender.
Update settings
Field name	Typical values	Comment
up2dateUrl		Do not change
Component editor settings
Field name	Typical values	Comment
componentRendererUrl		Do not change
componentRendererAction		Do not change
operatingMode		Do not change.
Superuser settings
Field name	Typical values	Comment
administratorUserName		The root account name
administratorPassword		The root account password
administratorEmail		The root account email.

There are a few other settings in the file but those are not to be changed.

Deliver-application is controlled in the deliver.properties

Below “infoglueDeliver{Working/Preview/Live}{suffix}/WEB-INF/classes” there are a file called “deliver.properties”. It contains all settings for the Deliver-application if not specified in the application settings in management tool and the possible setting are listed below:

Cache settings for the component editor environment
Field name	Typical values	Comment
isPageCacheOn	true / false	Allways use true except for debugging purposes
useSelectivePageCacheUpdate	true / false	This sets so only affected pages are discarded during updates, can be set to false for debugging purposes.
session.timeout	3600	Sets the timeout on the extranet sessions.
expireCacheAutomatically	true / false	false is default.
cacheExpireInterval	1800000	Only set this value if you set expireCacheAutomatically=true – should not be used in cms really
Operating mode
Field name	Typical values	Comment
operatingMode	0, 2 or 3	This sets 0 for working, 2 for preview and 3 for live.
Edit On Sight
Field name	Typical values	Comment
editOnSite	True / false
editOnSiteUrl
WEB-SPECIFIC SETTINGS (USED TO LOCATE IMAGES ETC)
Field name	Typical values	Comment
webServerAddress
applicationBaseAction
digitalAssetBaseUrl
imagesBaseUrl
digitalAssetPath
enableNiceURI
niceURIEncoding
disableEmptyUrls
requestArgumentDelimiter
Encoding settings
Field name	Typical values	Comment
URIEncoding	UTF-8	Descides in which way the urls in the tools are generated. If you have internation characters in role/user or group names this will be important.
Logging
Field name	Typical values	Comment
logDatabaseMessages	true / false	Allways use true except for debugging purposes
logToConsole	true / false	false is default.
logToFile	true / false	false is default.
logPath
logLevel
statisticsLogPath
statisticsLogOneFilePerDay
statisticsLogger
Database setting
Field name	Typical values	Comment
useShortTableNames	false	SET THIS TO TRUE IF YOU ARE RUNNING ORACLE OR DB2.
Portal setting
Field name	Typical values	Comment
enablePortal	true/false
portletBase
Mail settings
Field name	Typical values	Comment
mail.smtp.host
mail.smtp.auth
mail.smtp.user
mail.smtp.password
systemEmailSender
Update settings
Field name	Typical values	Comment
up2dateUrl
Component editor settings
Field name	Typical values	Comment
componentEditorUrl