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>
Mail-Followup-To: commons-dev@jakarta.apache.org
To: commons-dev@jakarta.apache.org
From: =?ISO-8859-15?Q?J=F6rg?= Schaible <joerg.schaible@gmx.de>
Subject: Re: [configuration]Release 1 and hierarchical configurations
Date: Fri, 02 Apr 2004 22:55:57 +0200
Lines: 36
Message-ID: <c4kk0t$heq$1@sea.gmane.org>
References: <406DB330.2010804@t-online.de>
Reply-To: joerg.schaible@gmx.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8Bit
Mail-Copies-To: never
User-Agent: KNode/0.7.7
Sender: news <news@sea.gmane.org>

Oliver Heger wrote:

> 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.)

Just popped in my mind: What's the big difference between a Subset and a
ConfigurationNode then ? IMHO the Subset *is* the Node for
HierarchicalConfigurations ... 

Regards,
J�rg


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