4.16.3 Component configuration

4.16.3.1 The API

The current configuration system is an interim solution, mainly for backwards compatibility with our older runtime environment (Avalon Merlin). Nonetheless, it's not bad, though in the future we'll likely add more advanced features like runtime reloading and notification of configuration changes, and drop the use of Avalon-specific APIs.

For representing configuration information, we use, for historical reasons, the Avalon Configuration API. In this API, the configuration data is modeled as a tree of Configuration objects. Each Configuration object can have attributes and children. This structure maps quite well onto XML, though it doesn't support mixed content (= sibling text and element nodes). The Configuration API provides convenient methods for retrieving the data as various non-string types, e.g. Configuration.getAttributeAsInteger(name)

Components (beans) in need of configuration data don't read this directly from files, but retrieve it using a logical name from a component called the ConfigurationManager.

While beans could depend on the ConfigurationManager component, we rather not let them retrieve the information themselves, but supply them directly with the Configuration object. Also, sometimes we'd like to be able to specify default configuration information. For these purposes, we made a Spring extension.

4.16.3.1.1 Example

Suppose we have a class Foo like this:

import org.apache.avalon.framework.configuration.Configuration

public class Foo {
    public Foo(Configuration conf) {
       System.out.println(conf.getChild("message").getValue());
    }
}

We could now supply it with the Configuration object like this:

<beans              xmlns = "http://www.springframework.org/schema/beans"
              xmlns:daisy = "http://outerx.org/daisy/1.0#runtime-springext"
               xmlns:conf = "http://outerx.org/daisy/1.0#config-springext"
       xsi:schemaLocation = "http://www.springframework.org/schema/beans
                             http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
                             http://outerx.org/daisy/1.0#runtime-springext
                             http://daisycms.org/schemas/daisyruntime-springext.xsd
                             http://outerx.org/daisy/1.0#config-springext
                             http://daisycms.org/schemas/config-springext.xsd">

  <daisy:import-service id="configurationManager"
                         service="org.outerj.daisy.configuration.ConfigurationManager"/>

  <bean id="thing1" class="Foo">
    <constructor-arg>
      <conf:configuration group="mythings" name="foo" source="configurationManager"/>
    </constructor-arg>
  </bean>

</beans>

Note the following things:

• A namespace and schema location is defined for the configuration stuff
• We import the ConfigurationManager service, assuming it is exported by another container in the Daisy Runtime (which is the case for the repository server)
• We use the <conf:configuration> element to get the configuration from the ConfigurationManager. The group and name attribute are for addressing the configuration.

Optionally, one can specify default configuration:

  <bean id="thing1" class="Foo">
    <constructor-arg>
      <conf:configuration group="mythings" name="foo" source="configurationManager">
        <conf:default xmlns="">
          <message>No message configured!</message>
        </conf:default>
      </conf:configuration>
    </constructor-arg>
  </bean>

4.16.3.2 Configuring the configuration

So where does the ConfigurationManager gets its configuration from? From an XML file, for a default repository installation this file is called myconfig.xml and can be found in the repository data directory.

The myconfig.xml looks like this:

<targets>
  <target path="mythings/foo">
    <configuration>
      <message>Hello world!</message>
    </configuration>
  </target>
</targets>

The format of this file is again, for compatibility reasons, the same as it was for Avalon Merlin, where the path attributes pointed to targets (components) for which the configuration was intended.

The path attribute contains the group/name specified when retrieving the configuration. There can be as many of these <target> elements as desired.

4.16.3.2.1 Backwards compatible paths

If you look in the actual myconfig.xml of the repository server, you'll see things like this:

<target path="/daisy/repository/blobstore">

This path attribute does not correspond to the group/name structure. This path attribute is however backwards compatibility with the old runtime. Supporting these old paths avoids the need for users to update their existing configuration files and (for us) to adjust utilities which read/update the configuration file.

The ConfigurationManager maintains a mapping of old paths to new paths, this mapping is used when reading the myconfig.xml.

4.16.3.3 Configuration merging

When a default configuration is specified (using conf:default), and there is also an actual configuration, both are merged by means of a CascadingConfiguration.

4.16.3.4 Further exploration

The sources of the configuration stuff can be found in the Daisy source tree at

services/configuration