[
https://issues.apache.org/jira/browse/MAILET-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984492#action_12984492
]
Stefano Bagnara commented on MAILET-31:
---------------------------------------
About the nullable and sender we also have another option.
To be "strict" sender should never be "null", instead RFC talks about empty
(blank) address for the return path. So to create bounces we need an empty
sender (zero length string).
I find good that the api doesn't let you change the sender once you create the
mail because technically a change in the sender is something "hard", so I would
still prefer to use the createMail(String sender) and duplicateMail(String
sender, Mail original) and let people use empty string for the sender when
needed (bounces). On the other hand Mail sender is a MailAddress object, so we
have to decide what to do when the given sender is not a valid MailAddress:
should we add throws AddressException to both methods?
> 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.
