commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Oliver Heger)
Subject Re: [configuration]Release 1 and hierarchical configurations
Date Fri, 02 Apr 2004 19:53:11 GMT
Well, knowing that the results will be even more horrible I am not 
really motivated to do that. Such a hack would have to check a bunch of 
cases, e.g. a SubsetConfiguration wrapping a HierarchicalConfiguration, 
a CompositeConfiguration containing a HierarchicalConfiguration and more.

Another point is that the affected classes are probably not used yet, so 
we won't really loose anything. And I surely don't want to block the 


Eric Pugh wrote:

>While I think it is very kind of you to offer to drop the code for 1.0, and
>it may be the right think, what about putting in some sort of temporary hack
>for 1.0?  Is there some sort of maybe private/special method like
>getHackConfigurationXMLDoucment or maybe some sort of usage of instanceof
>that we document as crummy but good enough?  Then, this would give us an
>example of what to rearchitect?  We get it to pass the unit tests, cut 1.0,
>and then remove the hack so that the unit tests bug us to fix the problem?
>>-----Original Message-----
>>From: Oliver Heger []
>>Sent: Friday, April 02, 2004 8:39 PM
>>To: Jakarta Commons Developer List
>>Subject: [configuration]Release 1 and hierarchical configurations
>>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:
>To unsubscribe, e-mail:
>For additional commands, e-mail:

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

View raw message