[
https://issues.apache.org/jira/browse/JAMES-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17940289#comment-17940289
]
Jean Helou commented on JAMES-4125:
-----------------------------------
> As always the proposal makes loads of sense for the guice code but is likely
> hard to achieve with the legacy Spring code.
indeed, as discussed in the PR we have talked about deprecating spring for long
enough :D there are now viable guice alternatives for the spring app assembly.
> (but if we succeed to work through the Spring limitatins of course then +1)
I do think it would be doable using a custom mailet scope which is registered
using the mailet name, this would allow to have spring resolve the mailet
configuration on a per mailet basis in MailetLoaderBeanFactory. This is
effectively what is done using guice but with an anonymous scope registered on
the fly.
With that said I do not intend to invest time in the spring implementation
which we want to kill anyways, but I leave this comment as a pointer should
someone want to retrofit the loading mechanism on a spring assembly.
> Rework Mailet api
> ------------------
>
> Key: JAMES-4125
> URL: https://issues.apache.org/jira/browse/JAMES-4125
> Project: James Server
> Issue Type: Improvement
> Reporter: Jean Helou
> Assignee: Jean Helou
> Priority: Major
>
> While prototyping a new DKIM mailet which would sign with a sender's domain
> specific key instead of using a fixed private key I realized the design of
> the mailet API is ... perfectible.
>
> I propose the following changes
> # improve the GuiceMailetLoader to no longer rely on the init() method but
> instead bind the proper mailet config in a child context as is done for the
> GuiceMailRepositoryLoader.
> # apply default methods to the mailet api so implementing a mailet from
> scratch (not using GenericMailet{^}1{^}) is easier
> # change the Mailet interface to get rid of the getMailetConfig method
> entirely as it is only used to get the context and the error handlers from
> the engine
> ** it is not the mailet responsibility to provide the context to the engine
> ** the getConfig would be replaced by 2 methods to explicitely provide error
> handlers instead of relying on an undocumented convention
> ^1^ GenericMailet is both a Mailet and a MailetConfig which doesn´t sound
> quite right, it also implements default behaviours that would be better
> placed as default methods on the interface
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
