1.4.2.1. Configuration retrieval

The container performs the following steps to make eXo Container configuration retrieval, depending on the container type.

Configuration retrieval order for PortalContainer

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

  1. Default RootContainer configurations from .jar files at /conf/configuration.xml.

  2. Configurations from .ear and .war files at /META-INF/exo-conf/configuration.xml. In case of an .ear, if the configuration could be found inside the META-INF folder, it will use only this file and will ignore configuration files in the META-INF folder of the web applications included in the .ear file.

  3. External RootContainer configuration can be found at $AS_HOME/exo-conf/configuration.xml.

  4. Default PortalContainer configurations from .jar files at /conf/portal/configuration.xml.

  5. Web applications configurations from .war files at /WEB-INF/conf/configuration.xml.

  6. External configuration for services of named portal can be found at $AS_HOME/exo-conf/portal/$PORTAL_NAME/configuration.xml.

Configuration retrieval for StandaloneContainer

The container is initialized by looking into different locations. This container is used by non-portal applications. Configurations are overloaded in the following lookup sequence:

  1. Default StandaloneContainer configurations from JAR files at /conf/configuration.xml.

  2. Default StandaloneContainer configurations from JAR files at /conf/portal/configuration.xml.

  3. Web applications configurations from WAR files at /WEB-INF/conf/configuration.xml.

  4. Then depending on the StandaloneContainer configuration URL initialization:

    • If configuration URL was initialized to be added to services defaults, as below:

      // add configuration to the default services configurations from JARs/WARs
      
      StandaloneContainer.addConfigurationURL(containerConf);

      Configuration from added URL containerConf will override only services configured in the file.

    • If configuration URL is not initialized at all, it will be found at $AS_HOME/exo-configuration.xml. If $AS_HOME/exo-configuration.xml does not exist, the container will look for it at $AS_HOME/exo-conf/exo-configuration.xml location and if it is still not found and the StandaloneContainer instance obtained with the dedicated configuration ClassLoader, the container will try to retrieve the resource conf/exo-configuration.xml within the given ClassLoader.

General notes about the configuration retrieval

Warning

  • The .ear and .war files from which Kernel gets the configuration files for the RootContainer, are found thanks to a lookup inside the standard deployment folders, but so far those folders are only properly defined in case of JBoss AS, Tomcat and Jetty. For other application servers, you will need to use the System property described in the previous note.

  • Take care to have no dependencies 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 in the /conf/portal/configuration.xml file of a given .jar file, you must not do it from the /conf/portal/configuration.xml file of another .jar but from another configuration file loaded after configurations from .jar files: /conf/portal/configuration.xml.

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

The user/developer should be careful when configuring the same service in different configuration files. It is recommended to configure a service in its own JAR only. Or, in case of a portal configuration, strictly reconfigure the services in portal .war files or in an external configuration.

There are services that can be (or should be) configured more than once. This depends on the business logic of the service. A service may initialize the same resource (shared with other services) or may add a particular object to a set of objects (shared with other services too). In the first case, it is critical who will be the last, i.e. whose configuration will be used. In the second case, it does not matter who is the first and who is the last (if the parameter objects are independent).

Getting the effective configuration at runtime

The effective configuration of StandaloneContainer, RootContainer and/or PortalContainer can be known thanks to the getConfigurationXML() method that is exposed through JMX at the container's level. This method will give you the effective configuration in XML format that has been really interpreted by Kernel. This could be helpful to understand how a given component or plugin has been initialized.

Copyright ©. All rights reserved. eXo Platform SAS
blog comments powered byDisqus