commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [configuration] Some suggestions for configuration2
Date Sun, 16 Aug 2009 20:15:22 GMT

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.

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.

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?

Ralph


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


Mime
View raw message