[configuration]Hierarchical design

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

I finally found the time to work further on my hierarchical 
configuration design. The code and some unit tests can be found at
       http://www.oliver-heger.privat.t-online.de/hierarchicalconfig.zip

Some explanations: There is an interface ConfigurationNode describing a 
node in a hierarchical configuration. It is intended to be used mainly 
by an ExpressionEngine, a component that resolves keys for configuration 
properties and maps them to a (set of) configuration node(s). Different 
implementations of the ExpressionEngine interface will allow to use 
various ways of querying properties. An already requested extension 
would be a XPath expression engine.

Some methods have been added to the Configuration interface to make it 
more hierarchical. It is possible to access the configuration's parent, 
and with the getChild() method direct or indirect children can be 
accessed. Maybe the name getChild() is not really fitting. The methods 
takes a property key as argument and evaluates it using the current 
expression engine. The result must be a single node, for which a 
Configuration object is created and returned. Such configurations are 
really connected to the node structure of the original Configuration 
object. So changes of properties can be immideately seen by both objects.

The subset() method in opposite supports property keys that evaluate to 
arbitrary complex result sets. For the resulting nodes a 
ViewConfiguration is created, which provides a logic view on the 
original configuration structure. The view configuration is registered 
as event listener at the root of the original configuration structure; 
manipulations on that data cause the view configuration to be rebuilt.

There is also an alternative implementation of  CompositeConfiguration 
using ViewConfiguration: The new CompositeConfiguration maintains a list 
of sub configurations which can be inserted using the addConfiguration() 
method and which can later be retrieved by name or by index. From the 
configuration nodes contained in these sub configurations the 
CompositeConfiguration constructs a logic node hierarchy. This is done 
with the help of a NodeCombiner object, a means for combining two 
configuration node hierarchies. There are implementations of the 
NodeCombiner interface for creating override and union configurations.

I hope that this alternative implementation makes use of composite 
configurations easier. Changes can be done on the sub configurations and 
are immediately reflected in the composite. ConfigurationFactory could 
become simpler with this approach, too.

Well, this is surely not perfect, but I hope there are some ideas that 
are worth discussion. Please send me some comments!
Oliver

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