You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mailet-api@james.apache.org by "Stefano Bagnara (JIRA)" <ma...@james.apache.org> on 2011/01/20 13:20:43 UTC
[jira] Created: (MAILET-31) Mail cloning/creation should be
available through MailetContext
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.
[jira] Commented: (MAILET-31) Mail cloning/creation should be
available through MailetContext
Posted by "Norman Maurer (JIRA)" <ma...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MAILET-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984153#action_12984153 ]
Norman Maurer commented on MAILET-31:
-------------------------------------
I think I would add setSender(...) to the Mail interface. As a Mail can have a "null" sender and I don't like to much the need of use null as argument too ;)
So I would go with:
MailetContext.createMail();
MailetContext.duplicateMail(Mail source);
Or the other option would be
Mail.newInstance();
Mail.duplicate(Mail mail);
> 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.
[jira] Commented: (MAILET-31) Mail cloning/creation should be
available through MailetContext
Posted by "Stefano Bagnara (JIRA)" <ma...@james.apache.org>.
[ 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.
[jira] Commented: (MAILET-31) Mail cloning/creation should be
available through MailetContext
Posted by "Stefano Bagnara (JIRA)" <ma...@james.apache.org>.
[ 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.
[jira] Commented: (MAILET-31) Mail cloning/creation should be
available through MailetContext
Posted by "Norman Maurer (JIRA)" <ma...@james.apache.org>.
[ https://issues.apache.org/jira/browse/MAILET-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984587#action_12984587 ]
Norman Maurer commented on MAILET-31:
-------------------------------------
I have no strong opinion on this, but I can see your point. So do what you prefer ;)
> 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.