commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@t-online.de>
Subject Re: [configuration] Alternative ConfigurationFactory
Date Wed, 01 Mar 2006 20:00:51 GMT
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


Mime
View raw message