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