Let's stop and explain some parts of the eXo internals in order to understand the roles of these configuration files.

eXo Platform kernel groups runtime components in portal containers. A portal container holds all components to run a portal instance. It serves portal pages under the servlet context for his name.

The default portal container in eXo Platform is called simply "portal". This is why the default url for the samples is http://localhost:800/*portal*.

The default portal container can be configured directly inside exo.conf.dir.

But eXo Platform is capable of running several portal instances simultaneously on the same server. Each instance can be configured and customized independently via files located at : /gatein/conf/portal/$PORTAL_NAME, where $PORTAL_NAME is the name of the portal container.

Services that run inside a portal container are declared via xml configuration files like configuration.xml. Such files exists in jars, wars and below exo.conf.dir.

XML configuration files also serve as the main way to customize the portal via the multiple plugins offered by eXo components.

Additionally, xml files may contain variables that are populated via properties defined in configuration.properties. Hence, the configuration.properties serves as exposing some chosen variables that are necessary to configure eXo Platform in a server environment.

The system configuration is done mostly in configuration.properties. In most cases, this should be the only file a system administrator will need to configure.

In the Tomcat bundle, this file is located at /gatein/conf/configuration.properties

This file contains the builtin configuration for the "portal" portal container.

In most cases, you should not need to change this file.

In case your project does not want to use "portal" as the default portal, this file can be used to to import another PortalContainerDefinition into the root container.

This file is empty by default. This is where further customizations can be placed. Generally, custom configurations are provided by extension wars. But this file is the last loaded by the kernel. It has a higher priority over any other configuration file, including extensions. So it let's you override any internal component configuration.

This may turn very handy for services or configurations that are not exposed in configuration.properties, but you'd like to tune anyway.

For example, you could decide to change the default transaction timeout to 2 minutes with this piece of xml:

<component> 
    <key>org.exoplatform.services.transaction.TransactionService</key> 
    <type>org.exoplatform.services.transaction.jbosscache.JBossTransactionsService</type> 
    <init-params> 
      <value-param> 
        <name>timeout</name> 
        <value>120</value> 
      </value-param> 
    </init-params> 
  </component>

eXo needs read/write access to several pathes in the local filesystem.

gatein.data.dir=../gatein/data

# path for any JCR data 
gatein.jcr.data.dir=${gatein.data.dir}/jcr

# path for file data inserted in JCR
gatein.jcr.storage.data.dir=${gatein.jcr.data.dir}/values

# path for the jcr index
gatein.jcr.index.data.dir=${gatein.jcr.data.dir}/index

The following table explains what goes in what path. The temporary? column indicates if the data is temporary or persistent.

Each variable can be defined as an absolute or relative path. The default configuration combines them to obtain a compact tree :

/gatein       # gatein.data.dir
  /data
    /hsql
    /jcr      # gatein.jcr.data.dir
      /index  # gatein.jcr.index.data.dir    
      /swap
      /values # gatein.jcr.storage.data.dir    
    /jta      

eXo Platform requires an SMTP server in order to send emails such as notificaitons or password reminders.

gatein.email.smtp.username=
gatein.email.smtp.password=
gatein.email.smtp.host=smtp.gmail.com
gatein.email.smtp.port=465
gatein.email.smtp.starttls.enable=true
gatein.email.smtp.auth=true
gatein.email.smtp.socketFactory.port=465
gatein.email.smtp.socketFactory.class=javax.net.ssl.SSLSocketFactory

More details con be found in the JavaMail API documentation.

The embedded WebDAV server lets you control the cache-control http header that it transmits to clients by mimetype. This is useful for fine-tuning your website.

The configuration property is: exo.webdav.cache-control

exo.webdav.cache-control=text/*:max-age=3600;image/*:max-age=1800;*/*:no-cache;

The property expects a comma-separated list of key=pair values, where keys are a list of mimetypes followed by the cache-control value to set.

Logging in eXo Platform is controlled by the Java Logging API.

By default, logging is configured to:

In Tomcat, the logging is configured via the conf/logging.properties file. Please refer to Tomcat's Logging Documentation for more information on how to adjust this file to your needs.

A set of properties control the behaviour of the JCR.

# Type of JCR configuration to use. Possible values are : 
# local : local JBC configuration
# cluster : cluster JBC configuration
gatein.jcr.config.type=local

# This is the filter used to notify changes in the jcr index
# in cluster mode, use org.exoplatform.services.jcr.impl.core.query.jbosscache.JBossCacheIndexChangesFilter
gatein.jcr.index.changefilterclass=org.exoplatform.services.jcr.impl.core.query.DefaultChangesFilter

# JCR cache configuration
gatein.jcr.cache.config=classpath:/conf/jcr/jbosscache/${gatein.jcr.config.type}/config.xml

# JCR Locks configuration
gatein.jcr.lock.cache.config=classpath:/conf/jcr/jbosscache/${gatein.jcr.config.type}/lock-config.xml

# JCR Index configuration
gatein.jcr.index.cache.config=classpath:/conf/jcr/jbosscache/cluster/indexer-config.xml
gatein.jcr.jgroups.config=classpath:/conf/jcr/jbosscache/cluster/udp-mux.xml

Please refer to the JCR reference guide for the details of configuring these files.