commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Oliver Heger)
Subject [configuration][PATCH]HierarchicalConfiguration
Date Mon, 20 Oct 2003 13:02:10 GMT

I have now created a patch with my first implementation of
HierarchicalConfiguration and related classes. Here are some remarks to the
new classes:

This is a base class for configuration classes that use a hierarchical
schema to store their properties. The class is fully functional and provides
meaningful implementations for all abstract methods defined in

A sub class of HierarchicalConfiguration that allows to parse XML documents
using DOM4J. This class does the same as DOM4JConfiguration, but keeps the
structure of the parsed documents. Saving of configuration properties is not
implemented yet.

This class is a faked SAX parser that operates on HierarchicalConfiguration
objects. It processes a configuration object and generates corresponding SAX
events that can be caught and evaluated by a ContentHandler implementation.
The associated unit test shows how this class can be used to construct a
DOM4J document from a configuration object. With this class it should also
be possible to feed configuration objects into a Digester.

This class is used internaly to construct keys and iterate over the single
parts a key consists of. I made it public because it may be useful for
clients as well. The class hides the concrete syntax of a property key, so
instead of dealing with strings, property delimiters, index or attribute
markers a client only needs to call methods of this class.

There are unit tests for each of these classes; according to the reports
they have a quite high coverage rate ;-)

Please send me your critics, ideas and suggestions and your thoughts how
(and if) to integrate this stuff with the existing code. I think the concept
of transforming a Configuration object to XML by using a simplified SAX
parser could be useful for non hierarchical configuration objects, too. So
it would be nice to have a corresponding implementation.

Then there is another idea that came me when I wrote
HierarchicalDOM4JConfiguration: How about separating the code for writing
configuration objects from the configuration classes? There could be
different ConfigurationOutputter classes for different formats (properties,
XML, ...). This would have a couple of advantages, e.g. it would allow to
save configuration data in another format than it was loaded from.

What do you mean?


View raw message