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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
