commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@oliver-heger.de>
Subject Re: [configuration] Some suggestions for configuration2
Date Sun, 16 Aug 2009 20:25:15 GMT
Ralph Goers schrieb:
> 
> On Aug 16, 2009, at 1:01 PM, Oliver Heger wrote:
> 
>> Recently I did some experiments in the base package of the 
>> configuration2 branch (the new package was used mainly to keep the 
>> code separated from the other classes). I would like to share the 
>> results with others and get some feedback.
>>
>> A new Configuration interface was created which includes methods from 
>> the original Configuration interface, from AbstractConfiguration, and 
>> from HierarchicalConfiguration. The goal is to provide a rich API for 
>> dealing with all kinds of - especially hierarchical - configuration 
>> settings.
>>
>> With ConfigurationImpl there is a default implementation of the 
>> Configuration interface. Note that this is not an abstract class, but 
>> a fully functional implementation of all interface methods. This could 
>> be achieved by separating the logic for actually accessing 
>> configuration data into a new concept: a configuration source.
>>
>> The basic idea is that a configuration source provides low-level 
>> access methods for "raw" configuration properties. ConfigurationImpl 
>> can build more powerful operations on top of a configuration source. 
>> One advantage of this concept is a better separation of concerns, 
>> which has some consequences:
>>
>> - To implement access to a new configuration source a developer does 
>> not have to extend a full-blown configuration class any more, but can 
>> focus on the much leaner ConfigurationSource interface.
>> - A Configuration is now more a view of a configuration source 
>> providing a richer API on top of it. Because the source holds the 
>> actual data it is sufficient to move this object to all interested 
>> parties rather than the Configuration with all its helper objects. 
>> Maybe a solution for our serialization problem?
>> - For low-level manipulations of configuration settings the source can 
>> be accessed directly. Features like loading and saving data would also 
>> reside in the source. Maybe the proposed flush() and sync() operations 
>> can be added here?
>>
>> Currently, there are two kinds of configuration sources with a 
>> different API: ConfigurationSource which provides a "flat" view on its 
>> properties, and HierarchicalConfigurationSource which organizes its 
>> data in a tree-like structure. ConfigurationImpl uses the latter for 
>> implementing truly hierarchical operations. There is an adapter class 
>> for transforming a flat configuration source into a hierarchical one.
>>
>> This is more or less the current status. WDYT?
> 
> I saw the check-ins but haven't had a chance to review them yet. When 
> you were checking them in for some reason I thought a 
> ConfigurationSource was going to be something that represented an event. 
> I'm not really sure why.
Maybe because these sources also support an event listener mechanism for 
low-level events. This could be useful e.g. for reload events or 
something like that.


> 
> But I conceptually support what you are describing above. My only 
> concern is that at the moment configuration2 is a bit of a mess with 
> multiple implementations of things in different packages, so it can be 
> difficult to make changes when you aren't sure which is the "real" class.
This is certainly true. If we agree on an approach, we can remove all 
other concepts/approaches/classes.

> 
> Has the new code been integrated to the point where the unit tests pass 
> using it?  Has the nonsense with attribute and node delimiters been 
> removed?
The unit tests have been copied from other classes (e.g. 
AbstractHierarchicalConfiguration) and slightly modified. This should 
ensure that the basic functionality is there and working.

I have not dealt with the delimiter stuff yet, but am +1 for removing 
the attribute splitting. The splitting of values should be disabled per 
default IMHO, too.

Oliver

> 
> Ralph
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message