commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: [Configuration] HierarchicalConfiguration in configuration2
Date Thu, 13 Nov 2008 07:56:17 GMT
The problem is that in applications using commons config they would like 
to specify an interface in lots of places. HierarchicalConfiguration 
would be perfect for that. It should just extend the Configuration 

I'm also a little confused over CombinedConfiguration and 
ExpressionEngine since two versions of these classes are present. I am 
assuming that combined/CombinedConfiguration and expr/ExpressionEngine 
are the correct classes and the others should be removed?


Oliver Heger wrote:
> Ralph Goers schrieb:
>> I've noticed that HierarchicalConfiguration isn't part of the 
>> inheritance for the various hierarchical implementations. This seems 
>> rather odd. What base class are applications migrating to 
>> configuration2 supposed to convert all their references to?  In fact, 
>> I'm wondering if HierarchicalConfiguration shouldn't just be 
>> converted to an interface that AbstractHierarchicalConfiguration 
>> implements.
> Well, first of all, this branch is really experimental and far from 
> being stable.
> For configuration2 the intension was to make all configurations 
> hierarchical. Because of this there does not seem to be much point in 
> calling a configuration class "HierarchicalConfiguration".
> The HierarchicalConfiguration class exists there for legacy reasons 
> only because some classes still rely on it. When refactoring is 
> complete it can be removed. With AbstractHierarchicalConfiguration 
> there is a new implementation based on the new NodeHandler approach. 
> (Later this class will probably merge with AbstractConfiguration.) The 
> new counterpart to HierarchicalConfiguration is called 
> InMemoryConfiguration.
> But, as you certainly see, there is still a lot of work to do, and 
> also some fundamental decisions are pending. For instance, what should 
> be the exact content of the Configuration interface? I am still on the 
> opinion that it would be a good idea to have a low-level 
> ConfigurationSource interface covering only the basics of property 
> access and a high-level Configuration interface providing a rich API 
> with many convenience methods.
> Oliver
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message