6.3. Configuration syntax

The following topics are covered:

Components

A service component is defined in the configuration.xml file by using <component> element.

There is only one required information when defining a service - the service implementation class, specified using <type>.

Every component has a <key> that identifies it. If not explicitly set, a key defaults to the value of <type>. If the key is loaded as a class, the Class or String object will be used as a key.

The usual approach is to specify an interface as a key.

Example: Example of service component configuration:


<?xml version="1.0" encoding="ISO-8859-1"?>
  <configuration
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd
                            http://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
        xmlns="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">
     <component>
        <key>org.exoplatform.services.database.HibernateService</key>
        <type>org.exoplatform.services.database.impl.HibernateServiceImpl</type>

        ...

     </component>
  </configuration>

External plugins

GateIn Kernel supports non-component objects that can be configured, instantiated, and injected into registered components, using method calls. The mechanism is called 'plugins', and allows portal extensions to add additional configurations to core services.

The external plugin is defined by using the <external-component-plugins> wrapper element which contains one or more <component-plugin> definitions. <external-component-plugins> uses <target-component> to specify a target service component that will receive injected objects.

Every <component-plugin> defines an implementation type, and a method on the target component to use for the injection (<set-method>).

A plugin implementation class has to implement the org.exoplatform.container.component. ComponentPlugin interface.

In the following example, PortalContainerDefinitionPlugin implements ComponentPlugin:

Example: PortalContainerDefinitionPlugin


<?xml version="1.0" encoding="UTF-8"?>
  <configuration
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd
                            http://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
        xmlns="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">

     <external-component-plugins>
        <target-component>org.exoplatform.container.definition.PortalContainerConfig</target-component>
        <component-plugin>
           <!-- The name of the plugin -->
           <name>Add PortalContainer Definitions</name>

           <!-- The name of the method to call on the PortalContainerConfig
                in order to register the PortalContainerDefinitions -->
           <set-method>registerPlugin</set-method>

           <!-- The fully qualified name of the PortalContainerDefinitionPlugin -->
           <type>org.exoplatform.container.definition.PortalContainerDefinitionPlugin</type>

           ...

        </component-plugin>
     </external-component-plugins>
  </configuration>

Includes and special URLs

It is possible to break the configuration.xml file into many smaller files, that are then included into a 'master' configuration file. The included files are complete configuration.xml documents, not fragments of text.

The following is an example of configuration.xml which 'outsources' its content into several files:


<configuration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd
                            http://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
        xmlns="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">

     <import>war:/conf/sample-ext/jcr/jcr-configuration.xml</import>
     <import>war:/conf/sample-ext/portal/portal-configuration.xml</import>
</configuration>

The special URL is used to refer to another configuration file. The URL schema 'war:' means that the path following is resolved that is related to the current PortalContainer's servlet context resource path, starting at WEB-INF as the root.

Note

The current PortalContainer is really a newly created PortalContainer, as war: URLs only make sense for PortalContainer scoped configuration.

Also, thanks to the extension mechanism, the servlet context used for resource loading is a unified servlet context (as explained in a later section).

To include the resolved path related to the current classpath (context classloader), use the 'jar:' URL schema.

Special variables

The configuration files may contain a special variable reference ${container.name.suffix}. This variable resolves to the name of the current portal container, prefixed by underscore (_). This facilitates reuse of configuration files in cases where portal specific unique names need to be assigned to some resources (For example, JNDI names, Database / DataSource names, JCR repository names).

This variable is only defined when there is a current PortalContainer available - only for PortalContainer scoped services.

A good example for this is HibernateService:

Example: HibernateService using variables


<?xml version="1.0" encoding="ISO-8859-1"?>
  <configuration
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd
                         http://www.exoplaform.org/xml/ns/kernel_1_0.xsd"
     xmlns="http://www.exoplaform.org/xml/ns/kernel_1_0.xsd">

     <component>
        <key>org.exoplatform.services.database.HibernateService</key>
        <jmx-name>database:type=HibernateService</jmx-name>
        <type>org.exoplatform.services.database.impl.HibernateServiceImpl</type>
        <init-params>
           <properties-param>
              <name>hibernate.properties</name>
              <description>Default Hibernate Service</description>
              <property name="hibernate.show_sql" value="false" />
              <property name="hibernate.cglib.use_reflection_optimizer" value="true" />
              <property name="hibernate.connection.url"
                              value="jdbc:hsqldb:file:../temp/data/exodb${container.name.suffix}" />
              <property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver" />
              <property name="hibernate.connection.autocommit" value="true" />
              <property name="hibernate.connection.username" value="sa" />
              <property name="hibernate.connection.password" value="" />
              <property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect" />
              <property name="hibernate.c3p0.min_size" value="5" />
              <property name="hibernate.c3p0.max_size" value="20" />
              <property name="hibernate.c3p0.timeout" value="1800" />
              <property name="hibernate.c3p0.max_statements" value="50" />
           </properties-param>
        </init-params>
     </component>
</configuration>

See also

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