RE: [configuration] Alternative ConfigurationFactory

[Jörg Schaible <Jo...@Elsag-Solutions.com>]

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

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

- Jörg

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

Re: [configuration] Alternative ConfigurationFactory

[Oliver Heger <ol...@t-online.de>]

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