commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <oliver.he...@t-online.de>
Subject [configuration] Alternative ConfigurationFactory
Date Sun, 26 Feb 2006 19:25:19 GMT
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.

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.

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

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