[
https://issues.apache.org/jira/browse/JAMES-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17146140#comment-17146140
]
Ioan Eugen Stan commented on JAMES-2335:
----------------------------------------
[~dleangen]
Apache Commons Configuration can read properties from all kinds of sources
https://commons.apache.org/proper/commons-configuration/ and
https://github.com/apache/commons-configuration/
https://github.com/apache/commons-configuration/blob/master/src/main/java/org/apache/commons/configuration2/YAMLConfiguration.java
We just need to write configurations in those sources and use them.
I tend to prefer YAML or TOML since they allow for comments and structure and
are easier to read than XML or JSON.
We can read configuration from the database as well - for the JPA
implementation ( [~btellier] mentioned writing a Cassandra provider to store
configs in Cassandra ).
[~btellier]: Some remarks regarding configuration and how it's used.
I believe parsing, loading and saving the configuration is the application's
responsibility not the modules responsibility.
I have seen a lot of modules depending on the commons-configuration jar and I
think it should not be so.
Modules that need configuration should define a POJO or a Map of properties
they use as configuration.
The POJO / Map is handed to them by the application on creation.
The modules / components should not normally need to Set / Update their
configuration.
It's normally the application's concern.
For services that have a dynamic configuration, they will need to use a
configuration provider factory - a class that produces the latest configuration.
That latest configuration can be read and cached by the application centrally
and injected in the configuration provider factory.
OSGi ConfigurationAdmin does this quite well actually.
> 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
