commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration]Release 1 and hierarchical configurations
Date Fri, 02 Apr 2004 19:26:36 GMT
Oliver,

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?

Comments?

Eric

> -----Original Message-----
> From: Oliver Heger [mailto:Oliver.Heger@t-online.de]
> 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:
>
> - ConfigurationXMLDocument.java and its test class
> TestConfigurationXMLDocument.java.
> - 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
> properties.
>
> Oliver
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message