You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Benoit Tellier (Jira)" <se...@james.apache.org> on 2019/11/18 04:45:00 UTC
[jira] [Updated] (JAMES-2335) Modernize James configuration
[ https://issues.apache.org/jira/browse/JAMES-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benoit Tellier updated JAMES-2335:
----------------------------------
Labels: feature refactoring (was: feature gsoc2018 refactoring)
> Modernize James configuration
> -----------------------------
>
> Key: JAMES-2335
> URL: https://issues.apache.org/jira/browse/JAMES-2335
> Project: James Server
> Issue Type: Improvement
> Components: configuration
> Reporter: Benoit Tellier
> Priority: Major
> Labels: feature, refactoring
>
> 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
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org