commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [Configuration] HierarchicalConfiguration in configuration2
Date Sat, 13 Dec 2008 20:42:14 GMT
Ralph Goers schrieb:
> On Dec 13, 2008, at 7:28 AM, Oliver Heger wrote:
>> There are of course configurations like MapConfiguration that are not 
>> hierarchical by nature. The classes in the "flat" package provide a 
>> hierarchical view on these classes. The idea is that when a 
>> hierarchical node structure is needed, it is constructed on the fly 
>> resulting in a root node and all properties stored in the 
>> configuration as child nodes. (So there is only a single layer 
>> hierarchy.)
>> But this is also experimental. I am not sure whether this is the way 
>> to go or whether these configurations should be transformed into true 
>> hierarchical configurations as is done by the 
>> ConfigurationUtils.convertToHierarchical() method.
> The problem I have is with the interface. Forcing applications to use 
> AbstractHierarchicalConfiguration as the "base" configuration object 
> they code to is wrong, IMO. Either they should use the Configuration 
> interface, which would need to include the hierarchical APIs such as 
> configurationAt, or they should use HierarchicalConfiguration, which 
> should be converted to an interface.
> If the goal - which I think was a good one - is to make everything be 
> hierarchical, then Flat is just a special case where no subtrees exist, 
> i.e. the root of the hierarchy is a leaf node. The only thing you really 
> need to do in that case is prohibit adding child nodes.
> So my recommendation would be to change the Configuration interface to 
> include the hierarchical methods.
> Ralph
I fully agree. It was intended to add the methods for hierarchical 
configurations to the Configuration interface, so that everything is 
available through this interface.

Unfortunately I did not make too much progress in refactoring the 
configuration2 branch. My idea was to make all configurations 
hierarchical first (and the flat package was a step into this direction) 
and then extend the Configuration interface. It would also be possible 
to do it the other way around; then we would have to add dummy 
implementations for the new methods to all configurations which are not 
yet hierarchical.


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

View raw message