[jira] [Commented] (JAMES-4125) Rework Mailet api

    [ 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)