[
https://issues.apache.org/jira/browse/MAILET-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984156#action_12984156
]
Stefano Bagnara commented on MAILET-31:
---------------------------------------
I currently prefer the MailetContext way. This give the container an
opportunity to easily track what mail objects are around.
Also Mail.newInstance can't be static, so you would create a new Mail instance
starting from another Mail instance: don't like this.
> Mail cloning/creation should be available through MailetContext
> ---------------------------------------------------------------
>
> Key: MAILET-31
> URL: https://issues.apache.org/jira/browse/MAILET-31
> Project: Mailet
> Issue Type: Improvement
> Components: Core API
> Affects Versions: 2.4
> Reporter: Stefano Bagnara
> Fix For: 2.5
>
>
> we have a bunch of mailets that are not generic because the duplicate the
> current "Mail". mailet api doesn't provide a way to do this, so our mailets
> simply have to use "new MailImpl(mail)".
> What about exposing message creation and message duplication methods from the
> mailet context? e.g:
> Mail createMail(String sender);
> Mail duplicateMail(String sender, Mail original);
> (as an alternative to have sender as a parameter we could add the
> setSender to the Mail interface. Not sure what's best)
> We could even use a single createMail(sender, original) with nullable
> original but I don't like too much "nullable" parameters.
> This way a mailet can create a new mail and enqueue it just using
> MailetContext.
> Not sure if we better should provide create + send (enqueue) methods or if we
> should instead provide something more "strict" in the api to allow a mailet
> to split a Mail returning multiple mails.
> As always we should start listing our current use cases.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
