On 18/05/2020 14:35, Matthieu Baechler wrote:
> On Sun, 2020-05-17 at 14:32 +0900, David Leangen wrote:
>> Hello,
[...]
>> I think Guice is easy enough that it would be worthwhile for me to
>> learn it, even if it’s just for James.
>>
>> On that note, what are the plans going forward regarding this topic?
>> Is there any intention to remove Spring? (It seems to me that Guice
>> is now the “preferred” way to use James.)
>>
>
> We still lack some customizations capabilities. @Benoit can you list
> them?
A huge effort toward this had been done as part of JAMES-2886 to allow
"custom" dependencies for user additional plugins.
In my opinion the only blocker is JDBC driver customization for the
"basic profile" (JPA) which is today unsupported.
All other customization capabilities might be an other anticipation of
people actual usage of Spring, and can be ported into Guice based
profiles if it makes sense other a transition period as part of Spring
profile deprecation then removal.
I bet some of these usage are oriented toward "James as a toolkit", and
can be achieved as discuss in this thread by a documentation effort for
Guice modules, cf:
https://www.mail-archive.com/server-dev@james.apache.org/msg65753.html
Some usages might be adding additional behaviors to an existing profile,
without recompiling it. JAMES-2886 again enables a user to load
additional Guice modules, that are composed with the server one upon
plugin dependency injection. This enables writing additional features
and adding them to a running James server without recompiling things nor
defining another "profile". The "extension" just needs to be packaged as
a Jar, and dropped in the extension-jar directory.
An example might be a "BlackList extension", composed of:
- The blackList component (API + implementation)
- A matcher that can be configured in mailetcontainer.xml
- And a REST administration endpoint to manage the blacklist.
Upon Spring -> Guice transition, we might have feature requests on
registration points we expose for such extensions.
To be honest, extensions could be in my opinion a mechanism used to
"split" core email server capabilities from side features (today we
package some features as disabled by default in the "profiles"). I think
good candidates for an extraction as an extension could be:
- SpamAssassin handling (mailet & listener)
- OverQuota mailing
- User search based on their quota
- Data Leak Prevention (DLP)
- mailbox/backup Import & Export of user data via a ZIP file
- DeletedMessageVault (restoring deleted messages)
This could help:
- To ensure enough tools are available for external extensions to be
written
- To limit the size and dependencies of existing "profiles"
- To rationalize the configuration of "profiles" that would thus be
limited to "core-components".
But maybe all of this should be discussed in a separate thread as a
"Guice roadmap"...
>
> Cheers,
>
> -- Matthieu Baechler
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
