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!
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]
