chibenwa commented on PR #2696: URL: https://github.com/apache/james-project/pull/2696#issuecomment-2769575785
``` The last 2 methods have an obvious implementation of using Option.empty but we would not use a default implementation on the interface. The GenericMailet would provide an implementation matching the current behaviour that extracts the value from the config. ``` As somebody extensively doing mailet configuration on a day to day basis I expect to be able to say :"manage errors from this mailet that way" with conf. Being able to do so arbitrarily with code had several time been invaluable. As such I'd expect this to *by design* remain the case. Thinking more about it those properties do not concern the mailets itself but the way the mailet container should run it. As such it do not seem legitimate to even have the mailet aware about this. What I think we are after is to add this `MailProcessingErrorHandlingConfiguration` config be part of the `MatcherMailetPair` and thus the mailet be transparent to it. AbstractStateMailetProcessor could initialise the `MailProcessingErrorHandlingConfiguration` at the same time than the mailet and the matcher. Bonus: we would not polute the mailet API with this, not change anything to the existing behaviour, and still achieve perfect encapsulation of the mailet config. Thoughts? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
