commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [configuration]Hierarchical design
Date Tue, 13 Apr 2004 09:00:38 GMT
imho Configuration and ConfigurationNode should be merged into a single 
class, because a Configuration is basically a node in a hierarchical design.

Emmanuel Bourg

Oliver Heger wrote:
> 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 
> involved.
> 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 
> release.
> 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.
> Regards
> Oliver
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message