the patch mentioned in my last posting also enhances ConfigurationFactory to support a union of some configurations defined in the XML definition file. As was suggested this works in the following way:
- XML elements defined in a <override> section or standalone work as before. They override properties defined in other configurations.
- XML elements in a <additional> section collect properties in a single configuration. They can be used to construct a union.
The basic idea behind this is quite simple: All configurations to be loaded in a <additional> section are added to a HierarchicalConfiguration object. The corresponding XML elements also support a new at attribute, which allows to specify a property key under which all properties are stored. This HierarchicalConfiguration is then added as last element to the CompositeConfiguration returned by ConfigurationFactory. So the logic of CompositeConfiguration needn't be changed: because configurations defined in an override section are added first to the CompositeConfiguration their properties are found first and thus override others; the union configuration is the last in this chain and is searched only if the requested key was not found before.
The existing unit tests run without changes; XML definition files without any <override> or <additional> section are treated as before. A new method in the unit test class tests the union capabilities. It loads a definition file which includes two HierarchicalDOM4JConfigurations and one PropertiesConfiguration in the <additional> section and one PropertiesConfiguration in the <override> section. The first <dom4j> element loads the database table definition I have often used as example. The second adds another table to it. The unit test checks now if the additional table can be found. The properties file in the override section defines some properties that are also defined in the other properties file. The test ensures that the correct (overriden) values are returned. I think this should cover all of the new features.
There was one strange thing that occurred to me: According to the examples in the documentation the elements that can be used in a definition file for ConfigurationFactory all have a className attribute that defines the configuration class to be used. These attributes have never been evaluated! (I was wondering about their existence anyway because the element name itself provides information about the class to use.) I have changed this so that now the attribute's value is taken into account; first to be consistent with the documentation and second because this was the easiest way to add support for my HierarchicalDOM4JConfiguration class.
Now I am expecting your comments!
Oli
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
