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