Container configuration

Each eXo container service may has configuration. Most of services has one with defaults which comes with the service JAR.

Each configurable service may be reconfigured to override defaults or set additional parameters. When container starts it searches for services and its configurations. And if the service has configured in two or more places the configuration override mechanism will be used.

Configurations search

Container performs following steps making eXo Container configurations search depending on container type.

Configurations apply order for PortalContainer

The container is initialized by looking into different locations. Configurations are overloaded in the following lookup sequence :

  1. Services default RootContainer configurations from JAR files /conf/configuration.xml
  2. External RootContainer configuration, if will be found at $AS_HOME/exo-conf/configuration.xml
  3. Services default PortalContainer configurations from JAR files /conf/portal/configuration.xml
  4. Web applications configurations from WAR files /WEB-INF/conf/configuration.xml
  5. External configuration for services of named portal, if will be found at $AS_HOME/exo-conf/portal/PORTAL_NAME/configuration.xml (since kernel 2.0.3)

Configurations apply order for StandaloneContainer

  1. Services default RootContainer configurations from JAR files /conf/configuration.xml
  2. External RootContainer configuration, if will be found at $AS_HOME/exo-conf/configuration.xml
then depending on StandaloneContainer configuration URL initialization,

if configuration URL was initialized to be added to services defaults 

// add configuration to the default services configurations from JARs/WARs
    StandaloneContainer.addConfigurationURL(containerConf);
  • Services default StandaloneContainer configurations from JAR files /conf/portal/configuration.xml
  • Web applications configurations from WAR files /WEB-INF/conf/configuration.xml
  • Configuration from added URL containerConf will override only services configured in the file
if configuration URL was initialized to override services defaults 
// full services configuration will be used instead of default ones from services JARs/WARs
    StandaloneContainer.setConfigurationURL(containerConf);
  • Overridden configuration only will be used (DEPRECATED, it's requirement to configure ALL services on which an application depends).
if configuration URL not initialized at all, the order is
  • Services default StandaloneContainer configurations from JAR files /conf/portal/configuration.xml
  • Web applications configurations from WAR files /WEB-INF/conf/configuration.xml
  • External configuration for StandaloneContainer services, if will be found at $AS_HOME/exo-configuration.xml. If $AS_HOME/exo-configuration.xml doesn't exist and StandaloneContainer instance obtained with dedicated configuration classloader the container will try to search resource conf/exo-configuration.xml within the given classloader.

Notes

$AS_HOME - application server home directory, or user.dir JVM system property value in case of Java Standalone application.

$PORTAL_NAME - portal web application name.

External configuration location cab be overridden with System property exo.conf.dir. If the property exists its value will be used as path to eXo configuration directory, i.e. to $AS_HOME/exo-conf alternative. E.g. put property in command line java -Dexo.conf.dir=/path/to/exo/conf (since kernel 2.0.4). In this particular use case, you have no need to use any prefix to import other files. For instance, if your configuration file is $AS_HOME/exo-conf/portal/PORTAL_NAME/configuration.xml and you want to import the configuration file $AS_HOME/exo-conf/portal/PORTAL_NAME/mySubConfDir/myConfig.xml, you can do it by adding <import>mySubConfDir/myConfig.xml</import> to your configuration file.

Under JBoss application server exo-conf will be looked up in directory described by JBoss System property jboss.server.config.url. If the property not found or empty $AS_HOME/exo-conf will be asked (since kernel 2.0.4).

The search looks for a configuration files in each JAR/WAR available from the classpath using current thread context classloader. And adds these configurations to a set. If the service was configured previously and the current JAR contains a new configuration of that service the latest (from the current JAR/WAR) will replace the previous one. The last replacing will be applied to the service at services start phase.

Warning: Take care to have no dependency between configurations from JAR files (/conf/portal/configuration.xml and /conf/configuration.xml) since we have no way to know in advance the loading order of those configurations. In other words, if you want to overload some configuration located into the file /conf/portal/configuration.xml of a given JAR file, you must not do it from the file /conf/portal/configuration.xml of another JAR file but from another configuration file loaded after configurations from JAR files /conf/portal/configuration.xml

After the processing of all configuration available in system the container will initialize it and start each service in order of dependency injection (DI).

In common case the user/developer should be careful in configuration of same service in different configuration files. It's recommended to configure service in own JAR only. Or, in case of portal configuration, strictly reconfigure valuable services in portal WAR files or in external configuration.

There are services that can be (or should be) configured some times. It's individual and depends on business logic of the service. A service may initialize same resource (shared with other services) or may add a particular object to a set of objects (shared for other services too). In first case it's a critical who will be the last, i.e. whose configuration will be used. In second case it's no matter who the first who the last (if parameter objects are independent).

Configuration search log

In case of problems with service configuration it's important to know from which JAR/WAR it comes. For that purpose JVM system property org.exoplatform.container.configuration.debug can be used.

java -Dorg.exoplatform.container.configuration.debug ...

If the property is enabled the container configuration manager will report configuration adding process to the standard output (System.out). 

......
   Add configuration jar:file:/D:/Projects/eXo/dev/exo-working/exo-tomcat/lib/exo.kernel.container-trunk.jar!/conf/portal/configuration.xml
   Add configuration jar:file:/D:/Projects/eXo/dev/exo-working/exo-tomcat/lib/exo.kernel.component.cache-trunk.jar!/conf/portal/configuration.xml
   Add configuration jndi:/localhost/portal/WEB-INF/conf/configuration.xml
        import jndi:/localhost/portal/WEB-INF/conf/common/common-configuration.xml
        import jndi:/localhost/portal/WEB-INF/conf/database/database-configuration.xml
        import jndi:/localhost/portal/WEB-INF/conf/ecm/jcr-component-plugins-configuration.xml
        import jndi:/localhost/portal/WEB-INF/conf/jcr/jcr-configuration.xml 
   ......

 
Products
generated on Tue Jan 06 14:40:29 UTC 2009
eXo Optional Modules
eXo Core Fundations
Recently Modified
Simple language for integrating dynamic content | eXo Products Roadmaps | eXo Enterprise Content Management | Create your own document type and associated Templates | ADVANCED HOW TO
Creator: Peter Nedonosko on 2008/07/09 10:23
Copyright (c) 2000-2009. Allright reserved - eXo platform SAS
1.6.13286