[
https://issues.apache.org/jira/browse/JAMES-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-4130.
---------------------------------
Resolution: Fixed
> 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
> Priority: Major
>
> 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
