[ https://issues.apache.org/jira/browse/JAMES-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16411088#comment-16411088 ]
Matthieu Baechler commented on JAMES-2335: ------------------------------------------ Hi [~phansson] Abstraction is ok for abstracting how to load a configuration from different sources. What we want is to have a meaningful configuration with business rules, a fluent API with sound default values, etc. Commons Configuration can very well be kept for loading configuration. > Modernize James configuration > ----------------------------- > > Key: JAMES-2335 > URL: https://issues.apache.org/jira/browse/JAMES-2335 > Project: James Server > Issue Type: Improvement > Components: configuration > Reporter: Tellier Benoit > Priority: Major > Labels: feature, gsoc2018, 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 (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org