commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <>
Subject RE: [configuration]Constructing a union of properties
Date Thu, 06 Nov 2003 20:31:28 GMT
I am traveling till monday, but I will check it out then..  Looks from first
blush pretty great!

> -----Original Message-----
> From: Oliver Heger []
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message