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 Thu, 13 Nov 2008 21:13:14 GMT
Ralph Goers schrieb:
> 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 
> interface.

It was discussed that in configuration2 all configurations are 
hierarchical. In this case there would be the single Configuration 
interface, but it would offer the enhanced functionality which is now 
provided by HierarchicalConfiguration.

> 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?
Yes, that's correct. Currently DefaultExpressionBuilder still uses the 
old classes because not all Configuration implementations supported by 
this class have been converted to the new model.


> Ralph
> 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:

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

View raw message