commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Oliver Heger)
Subject [configuration]Hierarchical design
Date Mon, 12 Apr 2004 18:40:39 GMT
I have been experimenting with a more hierarchical design for 
configuration classes and would like to bring in my results for 
discussion. You can download a zip under

What I have done so far is to extract the internal Node class from 
HierarchicalConfiguration. There is a new interface ConfigurationNode 
and an implementation called DefaultConfigurationNode. Also the 
evaluation of property keys was extracted from the configuration class. 
A new component, an expression engine, is now responsible for this task. 
This makes it possible to plug in different expression languages. I have 
created an implementation, which can evaluate the expressions supported 
by HierarchicalConfiguration so far.

The Configuration interface was extended by methods for setting and 
getting such an expression engine and a root node of a hierarchical 
configuration. If we deal mostly with hierarchical configuration 
sources, then maybe in the future HierarchicalConfiguration should 
replace BaseConfiguration as the one for all configuration base class, 
but this is open to discussion.

In this approach SubsetConfiguration can not simply be implemented by 
transforming property keys because interpretation of keys lies in the 
responsibility of the expression engine (and I doubt that such a 
transformation is always possible when complex expression languages like 
XPath are involved). So I came up with the concept of view 
configurations. As the name implies a view configuration provides a 
logic view to another configuration or set of configurations. To keep 
the view life I implemented a simple event notification system: the 
views register themselves at the original configuration and thus receive 
notifications whenever changes occur. A change causes a view to be 
rebuilt when it is accessed the next time. As the unit tests 
demonstrate, this works in both directions and also with multiple views 

The zip contains all classes and some unit tests. Note that I put all 
the stuff in a new hierarchy sub package, but that is only to have an 
independent code base and not to mess up some other classes before the 

Please have a look at the code and give me some feedback. If there is 
consensus that this approach should be followed, I can go ahead and 
re-implement CompositeConfiguration as a view configuration in both 
flavours: as overload and as union configuration. I think this would 
significantly reduce code in ConfigurationFactory and would make the 
planned refactorings much easier.


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

View raw message