[ 
https://issues.apache.org/jira/browse/JAMES-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146189#comment-17146189
 ] 

Matthieu Baechler commented on JAMES-2335:
------------------------------------------

Commons-configuration is a pain: old API, doesn't provide Optional type on 
reads, doesn't handle modern format like HOCON, etc.

I don't care if we keep it in the source code as long as it's in an optional 
module.

BTW, having commons-configuration types everywhere in the code is a pain for a 
long time: let's just pass parsed configuration as POJOs and then we'll choose 
the library we prefer, whatever it is.



> 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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to