commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Oliver Heger)
Subject [configuration]Release 1 and hierarchical configurations
Date Fri, 02 Apr 2004 18:38:40 GMT
There is still the problem that the ConfigurationXMLDocument class is 
not fully compatible with SubsetConfiguration. I don't think that a 
quick and clean solution can be found for this problem soon, so I would 
like to suggest to drop this class and some of its helpers from the 1.0 
release. The following files are affected:

- and its test class
- The three classes ending on XMLReader. Two of them have also test classes.
- In the XML howto document the last section starting with "XML 
processing" must be removed.
- In the conf directory testConfigurationXMLDocument.xml becomes obsolete.

In another thread it was mentioned that in future the inherent 
hierarchical aspects of configuration sources should be more regarded. 
So I hope that it will be quite easy to re-introduce these classes later 
with a cleaner design.

I was thinking a bit about those hierarchical aspects and how to provide 
access to them through the Configuration interface. My idea was to 
introduce an interface like ConfigurationNode that describes a node in a 
configuration tree. It could look similar to the 
HierarchicalProperties.Node class. Then a method getRoot() could be 
added to Configuration that returns the root node of the configuration 
tree thus providing a tree like view on a configuration. (By the way, 
there is already a class HierarchicalConfigurationConverter, which 
provides means to convert a flat configuration into a hierarchical one.)

If we had such a tree like view on a configuration, there could be 
different "expression language engines" operating on the trees, e.g. for 
XPath or other query languages. This would be a powerful way of querying 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message