[configuration]Constructing a union of properties

[Oliver Heger <Ol...@t-online.de>]

Hi again,

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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org

RE: [configuration]Constructing a union of properties

[Eric Pugh <ep...@upstate.com>]

I am traveling till monday, but I will check it out then..  Looks from first
blush pretty great!

> -----Original Message-----
> From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> Sent: Thursday, November 06, 2003 5:43 PM
> To: Jakarta Commons Developer List
> Subject: [configuration]Constructing a union of properties
>
>
> Hi again,
>
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org