[
https://issues.apache.org/jira/browse/JAMES-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17140606#comment-17140606
]
David Leangen commented on JAMES-2335:
--------------------------------------
{quote}We don't need OSGi to load/unload things at runtime. It's not hard to
load things into a sub-classloader.
{quote}
Yes, as I wrote above I agree with this point.
{quote}Do you mean Java modules are not providing that? I'm very curious, I
thought it does.
{quote}
There are some articles out there that explain the difference fairly well. Here
is one: [https://www.infoq.com/articles/java9-osgi-future-modularity/]
{quote}> Email is well-known. It seems to me that we ought to be able to
provide good Java APIs with interchangeable implementations.
Yet there's no good implementation out there.
{quote}
I am guessing that what you mean is "there is no good API out there".
Separation of API and implementation is very important for a well-written
service. A good API can have several competing implementations.
> The idea that email is a "done" topic is completely wrong: just search an
> IMAP client library and you'll see what I mean. Mime handling is not really
> better. I would not be writing email code if it already existed.
One of the problems I see is that the specs do do not appear to be very clear.
And of course there is always innovation.
When I wrote to the Mime4j list a few weeks ago, I was told something along the
lines that the spec does not really change, so there isn't much motivating is
updating the code.
> Sounds so cool. But you have to write code now or it doesn't exist, right?
Hahaha. Yes indeed. :)
Perhaps once I can understand the James codebase a little better I will give it
a shot.
> 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: [email protected]
For additional commands, e-mail: [email protected]
