Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <406DC4A7.5020805@t-online.de>
Date: Fri, 02 Apr 2004 21:53:11 +0200
From: Oliver.Heger@t-online.de (Oliver Heger)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [configuration]Release 1 and hierarchical configurations
References: <PKENIMMEAHDAHILNLIJPOEFCBMAB.epugh@upstate.com>
In-Reply-To: <PKENIMMEAHDAHILNLIJPOEFCBMAB.epugh@upstate.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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 
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: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
>
>
>  
>


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