Discussion moved over from James Dev as per Stefano's suggestion.
-------- Original Message --------
Subject: Re: [mailets] Proposal: MailetContext enhancement
Date: Sun, 18 Dec 2011 21:04:10 +0100
From: Stefano Bagnara <[email protected]>
Reply-To: James Developers List <[email protected]>
To: James Developers List <[email protected]>
2011/12/18 Steve Brewin<[email protected]>:
Hi
To decouple org.apache.james.transport mailets from
org.apache.james.core.MailImpl the following methods need to be added to
org.apache.mailet.Mail:
setRemoteAddr(String);
setRemoteHost(String);
setSender(MailAddress);
Nothing wrong with this in my view. They probably should have been there all
along!
What about adding these two?
- Mail createMail(MailAddress sender) => sets remoteaddr/host to the
local james address
- Mail cloneMail(Mail orig, MailAddress sender) => copies remoteaddr/host
I don't like to add too many public methods if they are not needed.
For what I remember the 2 methods above satisfy the current use case
BTW this is a mailet issue and we should move to the mailet ml and to
mailet-api JIRA, so that other interested parties (if any) can add
their opinion.
Here is an old proposal I just found:
https://issues.apache.org/jira/browse/MAILET-31
Stefano
The Mailets coupled to MailImpl are:
AbstractRecipientRewriteTable
AbstractRedirect
DSNBounce
Each uses new MailImpl(Mail) to create a new instance of Mail. This would
change to getMailetContext().createMail(Mail).
If we are to update MailetContext, which will require a new version of
Mailet API, we should make the changes to Mail in the same version.
Opinions?
Cheers
--Steve
On 18/12/2011 11:45, Steve Brewin wrote:
Missed...
createMail(Mail mail, Mail.State state)
...to satisfy the a need to create a copy of a Mail. I'll review the needs
of the org.apache.james.transport.mailets to make sure we haven't missed
anything else!
Cheers
--Steve
On 18/12/2011 10:25, Norman Maurer wrote:
Yeah I think the latter makes most sense.
Bye
Norman
2011/12/18, Steve Brewin<[email protected]>:
Hi Norman
Well I was trying to be less radical, but a createMail() method or
methods as a replacement for the sendMail() ones is a better solution.
If we were to have just a single create method, it would be:
createMail(MimeMessage message, Mail.State state)
Note that I have changed 'state' from a simple String to an enum.
As the API deals in things like MailAddress, it is perhaps reasonable to
add:
createMail(MailAddress sender, Collection<MailAddress> recipients,
MimeMessage message, Mail.State state)
The other variants are just helper methods that should not be forced on
an API. They could be implemented in Mailet Base if someone cared to do
so, as could the old sendMail() methods.
Cheers
--Steve
On 18/12/2011 08:52, Norman Maurer wrote:
Hi Steve,
I think it would make more sense to add a method to the MailetContext
to
create a new Mail object, so we could also make some other mailets that
are
currently using MailImpl directly independent of James Server.
So I'm in favor to add such a method and @deprecate all the
sendMail(..)
methods except the one the take a Mail object as parameter.
WDYT ?
Norman
2011/12/17 Steve Brewin<[email protected]>
For a new Mail, using MailetContext.sendMail(Mail mail) requires that
the
mailet knows how to create an implementation of Mail that is specific
to
the server hosting the Mailets. This breaks Mailet portability, which
is
why the other sendMail() methods exist.
MailetContext.sendMail(Mail mail) exists to resend an existing Mail,
the
others are for creating and sending new Mails.
--Steve
On 17/12/2011 19:53, Norman Maurer wrote:
I wonder why you can not use :
MailetContext.sendMail(Mail mail)
Can you give some more details ?
Bye,
Norman
2011/12/17 Steve Brewin<[email protected]>
Hi
Interface org.apache.mailet.****MailetContext defines four
sendMail()
methods that construct and send an org.apache.mailet.Mail instance.
None
of
these methods provide the ability to specify the mail attributes
that
should be attached.
I propose adding a further four methods mirroring the existing ones
each
with an extra parameter:
@param attributes
The Mail attributes to attach
This functionality is generally useful. The lack of it is a blocker
to
some SieveMailboxMailet enhancements.
Q1: Are there any objections to this?
Q2: The release version of the Mailet API is 2.4, so logically we
should
step to 2.5. There is already a 2.5 version in trunk containing a
few
changes. We can:
a) Combine the existing changes with these proposed changes
b) Park the existing changes and make 2.5 = 2.4 plus these proposed
changes
c) Something else?
Opinions please.
Q3: Whatever we decide to do for Q2, for JSieve development to
proceed
this version of the Mailet API needs to be implemented by
JamesMailetContext in James Server trunk. Are there any objections
to
this?
Cheers
--Steve
------------------------------****----------------------------**
--**---------
To unsubscribe, e-mail: server-dev-unsubscribe@james.****apache.org<
server-dev-**[email protected]<[email protected]>
For additional commands, e-mail:
[email protected].****org<
server-dev-help@james.**apache.org<[email protected]>>
------------------------------**------------------------------**---------
To unsubscribe, e-mail:
server-dev-unsubscribe@james.**apache.org<[email protected]>
For additional commands, e-mail:
[email protected].**org<[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
- - - - - - - - - - - - - - - - - -
This private and confidential e-mail has been sent to you by Synergy Systems
Limited. It may not represent the views of Synergy Systems Limited.
If you are not the intended recipient of this e-mail and have received it in error,
please notify the sender by replying with "received in error" as the subject
and then delete it from your mailbox.
