commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [configuration] New hierarchical configurations
Date Sun, 23 Mar 2008 20:07:24 GMT
Jörg Schaible wrote:
> Oliver Heger wrote:
>>I have added new hierarchical configuration implementations
>>based on the
>>node handler approach.
>>There is now a new AbstractHierarchicalConfiguration<T> class
>>providing basic functionality for dealing with hierarchical
>>Derived from that is InMemoryConfiguration, which is almost equivalent
>>to HierarchicalConfiguration. The new SubConfiguration class is the
>>counterpart to SubnodeConfiguration.
>>I copied the tests from the HierarchicalConfiguration, and they run
>>successful for the new configuration class. There are minor
>>differences in the handling of attributes: I decided not to allow
>>multiple values for an attribute as was possible for
>>HierarchicalConfiguration as part
>>of the list handling functionality. IMO this was rather
>>confusing than
>>helpful. Obviously these differences are not covered by the
>>unit tests.
>>Next steps are further configuration implementations based on the new
>>classes. I will do some experiments with XMLConfiguration and a new
>>preferences configuration class.
>>We can decide how to deal with the old classes. We could completely
>>replace them with the new ones or deprecate them only.
> For a major (incompatible) release 2.0 ... replace them. No need to burden ourselves
with old code maintenance. Get rid of old stuff as soon as possible.
> - Jörg
Agreed. After refactoring of the hierarchical file-based configurations
is complete, it shows that the new configurations are indeed a full
replacement for the old ones: all unit tests are still running.

About the naming: If all our configurations are hierarchical (at least
this is the plan currently), there does not seem to be much point in
calling a concrete implementation "HierarchicalConfiguration". Therefore
I used the name "InMemoryConfiguration" for the replacement (because the
whole data is stored as ConfigurationNode objects in memory).

In the first discussions about the new configuration2 branch somebody
suggested using a different package structure, which is more focused on
modularity, i.e. there should be packages containing configuration
implementations with a specific functionality. I would like to follow
this suggestion. Any objections or further comments?


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

View raw message