commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: [configuration] Alternative ConfigurationFactory
Date Wed, 01 Mar 2006 10:03:30 GMT
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


Mime
View raw message