[jira] [Created] (JAMES-4130) Allow alternative behaviour to GuiceJamesLoader

"Benoit Tellier (Jira)" <[email protected]>
Newsgroups gmane.comp.jakarta.james.devel
Message-ID <[email protected]>
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)
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.