Jörg Schaible wrote: >Hi Oliver, > > > >>-----Original Message----- >>From: Oliver Heger [mailto:[EMAIL PROTECTED] >>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). > > Hm, a poll on the mailing lists would be an option, but I doubt that we get a representive user base.
> > >>- 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. How about ConfigurationLoader? Or ConfigurationCollector? >- Jörg > > > Oliver --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
