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>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <4405FD73.5030700@t-online.de>
Date: Wed, 01 Mar 2006 21:00:51 +0100
From: Oliver Heger <oliver.heger@t-online.de>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [configuration] Alternative ConfigurationFactory
References: <F0D7281DAB048B438E8F5EC4ECEFBDDCB5C4C1@esmail.elsag.de>
In-Reply-To: <F0D7281DAB048B438E8F5EC4ECEFBDDCB5C4C1@esmail.elsag.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

J�rg Schaible wrote:

>Hi Oliver, 
>
>  
>
>>-----Original Message-----
>>From: Oliver Heger [mailto:oliver.heger@t-online.de] 
>>Sent: Sunday, February 26, 2006 8:25 PM
>>To: Jakarta Commons Developer List
>>Subject: [configuration] Alternative ConfigurationFactory
>>
>>I checked in an alternative configuration factory implementation named
>>XMLConfigurationFactory. This class differs from 
>>ConfigurationFactory in
>>the following points:
>>
>>- It does not depend on Commons Digester, but uses XMLConfiguration to
>>parse the definition file.
>>
>>- By inheriting from XMLConfiguration it is itself a 
>>FileConfiguration,
>>thus the definition file can be loaded from multiple sources.
>>
>>- It provides an easy mechanism of adding tags for custom 
>>configuration
>>implementations to the definition file using so called
>>ConfigurationProviders.
>>
>>- Complex initialization of the configuration sources to be loaded is
>>supported. For instance, it is possible to set the reloading 
>>strategy of
>>a file based configuration.
>>    
>>
>
>This sounds great.
>
>  
>
>>The implementations of these two factory classes are quite different,
>>they have almost none code in common. So I am not sure what's the best
>>way of dealing with this. We could
>>
>>- Merge both into a new ConfigurationFactory class. But if we want to
>>keep binary compatibility (which we should IMO), the result will be a
>>huge class with half of the code base being deprecated.
>>
>>- Let both classes coexist. This might confuse our users when 
>>they don't
>>know which one to choose.
>>    
>>
>
>Maybe a poll would be good to see if the users make usage of the different functionality (e.g. work with the digester rules or extend ConfigurationFactory).
>  
>
Hm, a poll on the mailing lists would be an option, but I doubt that we
get a representive user base.

>  
>
>>- Deprecate ConfigurationFactory in favour of 
>>XMLConfigurationFactory. I
>>guess that would be quite radical because ConfigurationFactory is
>>certainly widely used. Besides there are a few features of
>>ConfigurationFactory that the alternative does not support 
>>(overloading
>>digester rules, namespace support).
>>
>>Opinions? Are there other options?
>>    
>>
>
>Deprecation, but I would think over the name for the new factory. Something like ConfigurationBuilder would be also appropriate. Or you introduce ConfigurationBuilder as interface and have something like Configurations.getDefaultFactory().
>  
>
I am not too content with the name XMLConfigurationFactory either.
ConfigurationBuilder is fine, but there is a public inner class with
this name in ConfigurationFactory, so this could be a conflict. How
about ConfigurationLoader? Or ConfigurationCollector?

>- J�rg
>
>  
>
Oliver

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