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 release.
Oliver
Eric Pugh wrote:
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:[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
