Benoit Tellier created JAMES-4130:
-------------------------------------
Summary: Allow alternative behaviour to GuiceJamesLoader
Key: JAMES-4130
URL: https://issues.apache.org/jira/browse/JAMES-4130
Project: James Server
Issue Type: Improvement
Components: guice
Reporter: Benoit Tellier
h3. Why?
As a developper using James to assemblate my own app I whishes to wire my own
way to load extensions.
Historically, James extensions are very strict, and only well defined classes
are opened for extensions. This prevents the users to alterate James's inner
behaviour and make sense in order not to open a "support Pandora box" for the
ASF community.
Yet, as a software vendor relying on James to build a product I wish to have
more control over the extension assemblee.
Exemple: I cannot easily add Cassandra table definitions, I cannot add easily
webadmin tasks, I cannot add easily JMAP methods dynamically, etc...
I wishes to be able to combine Guice modules defained as extensions (and plug
directly into the exposed multi-binders.
h3. The blocker
Current GuiceGenericLoader hard codes the use of child modules wich is
incompatible with a combine strategy.
h3. What?
Hide GuiceGenericLoader behind an interface to allow app assemblee to define
their own and work around limitations cited above.
Appart from the new interface, which cost is minimal nothing changes for James
users.
h3. Alternative(s)
Require the user (me) to just define yet another list of extension modules,
distinct from extnesions.properties, which he would laod at app assembly? (Ok
to me too, though having 2 similarly named properties looks like quite complex
to me)
This approach have the benefits of doing no code changes to James, at the cost
of more complexity into the derivative.
h3. Side notes
LINAGORA plans to adopt this "combine" strategy to limit extension boiler plate
in our James derivative, Twake Mail. If the ASF community wishes to have a
structures return over experiment of this new set up we would hapily share it.
Idem for adopting this strategy in James itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
