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 Thu, 02 Mar 2006 07:23:45 GMT
Oliver Heger wrote on Wednesday, March 01, 2006 9:01 PM:
> Jörg Schaible wrote:

[snip]
 
>>> - 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.

Does it really matter? This is a complete different namespace. ConfigurationFactory.ConfigurationBuilder
should have been private anyway, it is only used within ContainerFactory and marked as internal
in the javadoc. Just rename this to a private ConfigurationFactory.Builder and for compatibility
extend a deprecated ConfigurationFactory.ConfigurationBuilder from it.

> How
> about ConfigurationLoader? Or ConfigurationCollector?

Well, it is the configuration of the configuration. ConfigurationInitializer?

Did you think about an interface for this? Does it make sense to have different implementations
of such builders/factories? Initialize from JNDI or DB (... or implement inclusion of other
configurations as part of the Configuration core interface)?

- 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