[ 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