[
https://issues.apache.org/jira/browse/JAMES-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17140521#comment-17140521
]
David Leangen commented on JAMES-2335:
--------------------------------------
I agree that the dynamic aspect of OSGi would not really add value to James. It
is relatively easy to do a static deployment, and IMO there wouldn't be a great
advantage to have a 24/7 server in this case.
But that is not the only nor even the main benefit of OSGi.
One huge benefit I see is the modularity. Yes, Java 9 modules are here, but
OSGi provides even better encapsulation. I think it is because it has been
around longer, and they didn't have to make the same compromises that Oracle
did. OSGi really makes dependency management so much easier and is enforced by
the classloader (which does not make available any "private" packages). Email
is well-known. It seems to me that we ought to be able to provide good Java
APIs with interchangeable implementations. The APIs ought to be pretty stable
by now. When I look in the codebase now, I am not able to easily pick them out.
I think that's a pity.
The separation of API / implementation makes semantic versioning and migration
a lot easier, especially when the API has been well thought out. The
implementation can continuously be updated without having any adverse effects
on the consumers. The way versions and dependency resolution works effectively
solves the problem of "jar hell".
Using Declarative Services seems to me to be a lot cleaner than Guice.
OSGi is very non-intrusive. Just a few annotations, and building with BND, make
it "just work".
It has a really advanced build system (BND) that works awesome with Gradle. :)
Resolving dependencies and packaging up distributions is really clean and easy.
I would not recommend OSGi for every project, but from what I have seen so far,
James seems like a perfect fit. This text is more of a late-night rant than a
well-thought description, but I hope it is useful anyway.
What we could do is carve out a little space that could be used as an
experiment. I could show how to build and deploy a module using Gradle/BND,
along with some of the using tooling that goes with it.
> 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
