[ 
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: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org

Reply via email to