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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
