james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tellier Benoit (JIRA)" <server-...@james.apache.org>
Subject [jira] [Updated] (JAMES-2335) Modernize James configuration
Date Thu, 08 Feb 2018 03:47:00 GMT

     [ https://issues.apache.org/jira/browse/JAMES-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Tellier Benoit updated JAMES-2335:
----------------------------------
    Description: 
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

  was:
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.

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


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


Mime
View raw message