commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <heg...@med.uni-marburg.de>
Subject Re: [configuration] Alternative ConfigurationFactory
Date Thu, 02 Mar 2006 15:13:54 GMT
Jörg Schaible wrote:
> Oliver Heger wrote on Wednesday, March 01, 2006 9:01 PM:
>> Jörg Schaible wrote:
>> 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.
> 
You are right, it probably does not matter. And I agree that the inner 
class should have been private from the beginning.

>> 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)?
> 
I have no concrete use case for multiple implementations of such an 
interface ATM, but this does not mean that it won't make sense. It is 
certainly possible that somebody might need to create a configuration 
from other sources or use a completly different form of the definition 
file. So I am +1 for an interface.

I am not sure what you mean by "implement inclusion of other 
configurations as part of the Configuration core interface". Should 
every Configuration implementation support the inclusion of other sources?

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