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). > - 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(). - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
