Apache James currently relies on commons-configuration, and thus on XML configuration files.
As such the configuration process has several problems:
- Working with XML is boiler plate
- Working with file leads to a real lack of flexibility.
- For instance, in a cluster environment, we would like all the James server to share the same configurations.
- Also, in tests, we need to test the different configuration values. We can not do this without overwriting files, which is dangerous, and boilerplate.
What we need is:
- To represent all possible configuration via java objects.
- Configuration providers should be able to convert the configuration stored into the java configuration object.
- We should be able to inject different configuration providers from guice/spring.
It would allow to specify alternative configuration backends (different formats, different storage techniques) and allow direct injection (for tests for instance).
Here would be the steps for this work:
- Add a Initializable class in lifecycle-api. This should be called by Guice and Sprint at initialization
- configure in Configurable will save a Java object (parse the HierachicalConfiguration into a java object representing it's content). Initialization will then be done by Initializable.
- Then we can move away, object by object, from the Configurable interface: We need to move the configuration parsing in a separated class (behind an interface). We can register ConfigurationProviders, with an XML/commons-configuration default implementation.
- Deprecate Configurable.
- Provide alternative configuration providers, for example, a Cassandra stored configuration provider