You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Steve Brewin <sb...@synsys.com> on 2011/12/17 19:00:25 UTC
[mailets] Proposal: MailetContext enhancement
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
For additional commands, e-mail: server-dev-help@james.apache.org
Fwd: Re: [mailets] Proposal: MailetContext enhancement
Posted by Steve Brewin <sb...@synsys.com>.
Discussion moved over from James Dev as per Stefano's suggestion.
-------- Original Message --------
Subject: Re: [mailets] Proposal: MailetContext enhancement
Date: Sun, 18 Dec 2011 19:56:49 +0100
From: Norman Maurer <no...@apache.org>
Reply-To: James Developers List <se...@james.apache.org>
To: James Developers List <se...@james.apache.org>
I would prefer more to just add a dispose() method to the Mail interface.
Bye,
Norman
--
Norman Maurer
Am Sonntag, 18. Dezember 2011 um 17:58 schrieb Steve Brewin:
> There's a problem with all of this!
>
> The sendMail(.) methods implemented by JamesMailetContext perform their
> processing within a try/catch/finally block where the finally stanza
> guarantees the invocation of LifecycleUtil.dispose(..) to release the
> resources held by the MailImpl instance.
>
> If, as proposed, we allow a MailContext to create a Mail, we can no
> longer guarantee that dispose will be called and therefore expose the
> server to resource leaks. Overriding Object.finalize() to call
> LifecycleUtil.dispose(..) cannot be relied on as it cannot be guaranteed
> that Mailet processing, which is outside of our control, correctly
> releases its resources so that the MailImpl is eventually garbage collected.
>
> Well>>could<< guarantee disposal by adding a further parameter to the
> createMail(..) methods enabling mailet behaviour to be performed within
> a try/catch/finally block where the finally stanza guarantees the
> invocation of LifecycleUtil.dispose(..) as before. For example, give...
>
> interface Performable {
> public void perform(Mail mail);
> }
>
> interface MailetContext {
> ...
> void createMail(Mail mail, new Performable();
> }
>
> ...we could safely write...
>
> void createMail(Mail mail, new Performable(){
> perform(Mail mail)
> {
> mail.setAttribute("key", "value");
> sendMail(mail, Mail.State.DEFAULT);
> }
> };
>
> I say>>could<< as this complicates things, perhaps more than is
> desirable. This said, I like it! Should we go this route we certainly
> need to add the sendMail(..) methods to Mailet Base to wrap this stuff,
> hiding the complications for simple use-cases.
>
> Opinions?
>
> Cheers
> --Steve
>
> On 18/12/2011 16:29, Steve Brewin wrote:
> > 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<sbrewin@synsys.com (mailto:sbrewin@synsys.com)>:
> > > > > 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<sbrewin@synsys.com (mailto:sbrewin@synsys.com)>
> > > > > >
> > > > > > > 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<sbrewin@synsys.com (mailto:sbrewin@synsys.com)>
> > > > > > > >
> > > > > > > > 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 (http://apache.org)<
> > > > > > > > > server-dev-**unsubscribe@james.apache.org (mailto:unsubscribe@james.apache.org)<server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)>
> > > > > > > > >
> > > > > > > > > For additional commands, e-mail:
> > > > > > > > > server-dev-help@james.apache (mailto:server-dev-help@james.apache).****org<
> > > > > > > > > server-dev-help@james.**apache.org<server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)>>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ------------------------------**------------------------------**---------
> > > > > > >
> > > > > > > To unsubscribe, e-mail:
> > > > > > > server-dev-unsubscribe@james.**apache.org<server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)>
> > > > > > >
> > > > > > > For additional commands, e-mail:
> > > > > > > server-dev-help@james.apache (mailto:server-dev-help@james.apache).**org<server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)>
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)
> > > > For additional commands, e-mail: server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)
> > > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)
> > For additional commands, e-mail: server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)
> For additional commands, e-mail: server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)
>
>
Re: Fwd: Re: [mailets] Proposal: MailetContext enhancement
Posted by Stefano Bagnara <ap...@bago.org>.
2011/12/19 Steve Brewin <sb...@synsys.com>:
> I created this as a proposal as I expected some disagreement along the way
> :)
>
> In my view changing from the Mailet container taking care of managing
> resources to placing the responsibility on the Mailet developer is a
> retrograde step that is unnecessary to achieve our objectives.
Once we add the methods to create a Mail to the MailetContext then the
MailetContext (e.g: the container) will be able to keep track of
resources and will be able to dispose them after service method
returned.
So, there is no need to make "dispose" method public.
> It also exposes the possibility for dispose() to be invoked inappropriately
> against Mail instances passed into the Mailet Container.
I guess the previous sentence makes this answer not useful, but anyway
I want to add that james is vulnerable to mailets and in no way try to
protect from malicious mailets (dispose would just be one more thing
in thousands).
> We would be destabilising much to achieve very little. What is so wrong with
> the proposed closure style solution I made earlier?
IMO it is unnecessary right now (but I maybe wrong, of course), as we
just need some more code in the container and some javadoc on the new
methods, explaining that mail instances returned by the 2 methods
cannot be referenced after service method return because the server
will dispose them. We could even automatically track if a mailet
creates a new mail object without actually sending/storing it.
Stefano
Re: Fwd: Re: [mailets] Proposal: MailetContext enhancement
Posted by Steve Brewin <sb...@synsys.com>.
I created this as a proposal as I expected some disagreement along the
way :)
In my view changing from the Mailet container taking care of managing
resources to placing the responsibility on the Mailet developer is a
retrograde step that is unnecessary to achieve our objectives.
It also exposes the possibility for dispose() to be invoked
inappropriately against Mail instances passed into the Mailet Container.
We would be destabilising much to achieve very little. What is so wrong
with the proposed closure style solution I made earlier?
Cheers
--Steve
On 19/12/2011 10:04, Steve Brewin wrote:
> Discussion moved over from James Dev as per Stefano's suggestion.
> -------- Original Message --------
> Subject: Re: [mailets] Proposal: MailetContext enhancement
> Date: Sun, 18 Dec 2011 20:25:53 +0100
> From: Norman Maurer <no...@googlemail.com>
> Reply-To: James Developers List <se...@james.apache.org>
> To: James Developers List <se...@james.apache.org>
> CC: server-dev@james.apache.org <se...@james.apache.org>
>
>
>
> I dont agree with you here... I think just have an dispose method is
> fine. Its not different the for example the need to close an
> EntityManager which is quite nature in the enterprise.
>
> bye
> norman
>
> Von meinem iPad gesendet
>
> Am 18.12.2011 um 19:45 schrieb Steve Brewin<sb...@synsys.com>:
>
>> Obviously this was my first thought, but this exposes the mail
>> server to compromise by Mailets that forget to call dispose() on
>> failure.
>>
>> If we want to be Enterprise strength, this isn't good enough as it
>> is too weak a contract. We must guarantee that dispose will be called
>> (my new solution), or prevent the exposure (the current solution).
>>
>> --Steve
>>
>> On 18/12/2011 18:56, Norman Maurer wrote:
>>> I would prefer more to just add a dispose() method to the Mail
>>> interface.
>>>
>>> Bye,
>>> Norman
>>>
>>>
>>
>> - - - - - - - - - - - - - - - - - -
>>
>> 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.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
>
Fwd: Re: [mailets] Proposal: MailetContext enhancement
Posted by Steve Brewin <sb...@synsys.com>.
Discussion moved over from James Dev as per Stefano's suggestion.
-------- Original Message --------
Subject: Re: [mailets] Proposal: MailetContext enhancement
Date: Sun, 18 Dec 2011 20:25:53 +0100
From: Norman Maurer <no...@googlemail.com>
Reply-To: James Developers List <se...@james.apache.org>
To: James Developers List <se...@james.apache.org>
CC: server-dev@james.apache.org <se...@james.apache.org>
I dont agree with you here... I think just have an dispose method is fine. Its not different the for example the need to close an EntityManager which is quite nature in the enterprise.
bye
norman
Von meinem iPad gesendet
Am 18.12.2011 um 19:45 schrieb Steve Brewin<sb...@synsys.com>:
> Obviously this was my first thought, but this exposes the mail server to compromise by Mailets that forget to call dispose() on failure.
>
> If we want to be Enterprise strength, this isn't good enough as it is too weak a contract. We must guarantee that dispose will be called (my new solution), or prevent the exposure (the current solution).
>
> --Steve
>
> On 18/12/2011 18:56, Norman Maurer wrote:
>> I would prefer more to just add a dispose() method to the Mail interface.
>>
>> Bye,
>> Norman
>>
>>
>
> - - - - - - - - - - - - - - - - - -
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mailets] Proposal: MailetContext enhancement
Posted by Norman Maurer <no...@googlemail.com>.
I dont agree with you here... I think just have an dispose method is fine. Its not different the for example the need to close an EntityManager which is quite nature in the enterprise.
bye
norman
Von meinem iPad gesendet
Am 18.12.2011 um 19:45 schrieb Steve Brewin <sb...@synsys.com>:
> Obviously this was my first thought, but this exposes the mail server to compromise by Mailets that forget to call dispose() on failure.
>
> If we want to be Enterprise strength, this isn't good enough as it is too weak a contract. We must guarantee that dispose will be called (my new solution), or prevent the exposure (the current solution).
>
> --Steve
>
> On 18/12/2011 18:56, Norman Maurer wrote:
>> I would prefer more to just add a dispose() method to the Mail interface.
>>
>> Bye,
>> Norman
>>
>>
>
> - - - - - - - - - - - - - - - - - -
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mailets] Proposal: MailetContext enhancement
Posted by Steve Brewin <sb...@synsys.com>.
Obviously this was my first thought, but this exposes the mail server to
compromise by Mailets that forget to call dispose() on failure.
If we want to be Enterprise strength, this isn't good enough as it is
too weak a contract. We must guarantee that dispose will be called (my
new solution), or prevent the exposure (the current solution).
--Steve
On 18/12/2011 18:56, Norman Maurer wrote:
> I would prefer more to just add a dispose() method to the Mail interface.
>
> Bye,
> Norman
>
>
- - - - - - - - - - - - - - - - - -
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mailets] Proposal: MailetContext enhancement
Posted by Norman Maurer <no...@apache.org>.
I would prefer more to just add a dispose() method to the Mail interface.
Bye,
Norman
--
Norman Maurer
Am Sonntag, 18. Dezember 2011 um 17:58 schrieb Steve Brewin:
> There's a problem with all of this!
>
> The sendMail(.) methods implemented by JamesMailetContext perform their
> processing within a try/catch/finally block where the finally stanza
> guarantees the invocation of LifecycleUtil.dispose(..) to release the
> resources held by the MailImpl instance.
>
> If, as proposed, we allow a MailContext to create a Mail, we can no
> longer guarantee that dispose will be called and therefore expose the
> server to resource leaks. Overriding Object.finalize() to call
> LifecycleUtil.dispose(..) cannot be relied on as it cannot be guaranteed
> that Mailet processing, which is outside of our control, correctly
> releases its resources so that the MailImpl is eventually garbage collected.
>
> Well >>could<< guarantee disposal by adding a further parameter to the
> createMail(..) methods enabling mailet behaviour to be performed within
> a try/catch/finally block where the finally stanza guarantees the
> invocation of LifecycleUtil.dispose(..) as before. For example, give...
>
> interface Performable {
> public void perform(Mail mail);
> }
>
> interface MailetContext {
> ...
> void createMail(Mail mail, new Performable();
> }
>
> ...we could safely write...
>
> void createMail(Mail mail, new Performable(){
> perform(Mail mail)
> {
> mail.setAttribute("key", "value");
> sendMail(mail, Mail.State.DEFAULT);
> }
> };
>
> I say >>could<< as this complicates things, perhaps more than is
> desirable. This said, I like it! Should we go this route we certainly
> need to add the sendMail(..) methods to Mailet Base to wrap this stuff,
> hiding the complications for simple use-cases.
>
> Opinions?
>
> Cheers
> --Steve
>
> On 18/12/2011 16:29, Steve Brewin wrote:
> > 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<sbrewin@synsys.com (mailto:sbrewin@synsys.com)>:
> > > > > 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<sbrewin@synsys.com (mailto:sbrewin@synsys.com)>
> > > > > >
> > > > > > > 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<sbrewin@synsys.com (mailto:sbrewin@synsys.com)>
> > > > > > > >
> > > > > > > > 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 (http://apache.org)<
> > > > > > > > > server-dev-**unsubscribe@james.apache.org (mailto:unsubscribe@james.apache.org)<server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)>
> > > > > > > > >
> > > > > > > > > For additional commands, e-mail:
> > > > > > > > > server-dev-help@james.apache (mailto:server-dev-help@james.apache).****org<
> > > > > > > > > server-dev-help@james.**apache.org<server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)>>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > ------------------------------**------------------------------**---------
> > > > > > >
> > > > > > > To unsubscribe, e-mail:
> > > > > > > server-dev-unsubscribe@james.**apache.org<server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)>
> > > > > > >
> > > > > > > For additional commands, e-mail:
> > > > > > > server-dev-help@james.apache (mailto:server-dev-help@james.apache).**org<server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)>
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)
> > > > For additional commands, e-mail: server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)
> > > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)
> > For additional commands, e-mail: server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org (mailto:server-dev-unsubscribe@james.apache.org)
> For additional commands, e-mail: server-dev-help@james.apache.org (mailto:server-dev-help@james.apache.org)
>
>
Re: [mailets] Proposal: MailetContext enhancement
Posted by Steve Brewin <sb...@synsys.com>.
There's a problem with all of this!
The sendMail(.) methods implemented by JamesMailetContext perform their
processing within a try/catch/finally block where the finally stanza
guarantees the invocation of LifecycleUtil.dispose(..) to release the
resources held by the MailImpl instance.
If, as proposed, we allow a MailContext to create a Mail, we can no
longer guarantee that dispose will be called and therefore expose the
server to resource leaks. Overriding Object.finalize() to call
LifecycleUtil.dispose(..) cannot be relied on as it cannot be guaranteed
that Mailet processing, which is outside of our control, correctly
releases its resources so that the MailImpl is eventually garbage collected.
Well >>could<< guarantee disposal by adding a further parameter to the
createMail(..) methods enabling mailet behaviour to be performed within
a try/catch/finally block where the finally stanza guarantees the
invocation of LifecycleUtil.dispose(..) as before. For example, give...
interface Performable {
public void perform(Mail mail);
}
interface MailetContext {
...
void createMail(Mail mail, new Performable();
}
...we could safely write...
void createMail(Mail mail, new Performable(){
perform(Mail mail)
{
mail.setAttribute("key", "value");
sendMail(mail, Mail.State.DEFAULT);
}
};
I say >>could<< as this complicates things, perhaps more than is
desirable. This said, I like it! Should we go this route we certainly
need to add the sendMail(..) methods to Mailet Base to wrap this stuff,
hiding the complications for simple use-cases.
Opinions?
Cheers
--Steve
On 18/12/2011 16:29, Steve Brewin wrote:
> 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<sb...@synsys.com>:
>>>> 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<sb...@synsys.com>
>>>>>
>>>>>> 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<sb...@synsys.com>
>>>>>>>
>>>>>>> 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-**unsubscribe@james.apache.org<se...@james.apache.org>
>>>>>>>>
>>>>>>>> For additional commands, e-mail:
>>>>>>>> server-dev-help@james.apache.****org<
>>>>>>>> server-dev-help@james.**apache.org<se...@james.apache.org>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> ------------------------------**------------------------------**---------
>>>>>>
>>>>>> To unsubscribe, e-mail:
>>>>>> server-dev-unsubscribe@james.**apache.org<se...@james.apache.org>
>>>>>>
>>>>>> For additional commands, e-mail:
>>>>>> server-dev-help@james.apache.**org<se...@james.apache.org>
>>>>>>
>>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Fwd: Re: [mailets] Proposal: MailetContext enhancement
Posted by Steve Brewin <sb...@synsys.com>.
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 <ap...@bago.org>
Reply-To: James Developers List <se...@james.apache.org>
To: James Developers List <se...@james.apache.org>
2011/12/18 Steve Brewin<sb...@synsys.com>:
> 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<sb...@synsys.com>:
>>>>
>>>> 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<sb...@synsys.com>
>>>>>
>>>>>> 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<sb...@synsys.com>
>>>>>>>
>>>>>>> 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-**unsubscribe@james.apache.org<se...@james.apache.org>
>>>>>>>> For additional commands, e-mail:
>>>>>>>> server-dev-help@james.apache.****org<
>>>>>>>>
>>>>>>>> server-dev-help@james.**apache.org<se...@james.apache.org>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> ------------------------------**------------------------------**---------
>>>>>> To unsubscribe, e-mail:
>>>>>>
>>>>>> server-dev-unsubscribe@james.**apache.org<se...@james.apache.org>
>>>>>> For additional commands, e-mail:
>>>>>> server-dev-help@james.apache.**org<se...@james.apache.org>
>>>>>>
>>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
- - - - - - - - - - - - - - - - - -
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.
Re: [mailets] Proposal: MailetContext enhancement
Posted by Stefano Bagnara <ap...@bago.org>.
2011/12/18 Steve Brewin <sb...@synsys.com>:
> 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<sb...@synsys.com>:
>>>>
>>>> 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<sb...@synsys.com>
>>>>>
>>>>>> 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<sb...@synsys.com>
>>>>>>>
>>>>>>> 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-**unsubscribe@james.apache.org<se...@james.apache.org>
>>>>>>>> For additional commands, e-mail:
>>>>>>>> server-dev-help@james.apache.****org<
>>>>>>>>
>>>>>>>> server-dev-help@james.**apache.org<se...@james.apache.org>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> ------------------------------**------------------------------**---------
>>>>>> To unsubscribe, e-mail:
>>>>>>
>>>>>> server-dev-unsubscribe@james.**apache.org<se...@james.apache.org>
>>>>>> For additional commands, e-mail:
>>>>>> server-dev-help@james.apache.**org<se...@james.apache.org>
>>>>>>
>>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mailets] Proposal: MailetContext enhancement
Posted by Steve Brewin <sb...@synsys.com>.
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<sb...@synsys.com>:
>>> 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<sb...@synsys.com>
>>>>
>>>>> 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<sb...@synsys.com>
>>>>>>
>>>>>> 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-**unsubscribe@james.apache.org<se...@james.apache.org>
>>>>>>>
>>>>>>> For additional commands, e-mail:
>>>>>>> server-dev-help@james.apache.****org<
>>>>>>> server-dev-help@james.**apache.org<se...@james.apache.org>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> ------------------------------**------------------------------**---------
>>>>>
>>>>> To unsubscribe, e-mail:
>>>>> server-dev-unsubscribe@james.**apache.org<se...@james.apache.org>
>>>>>
>>>>> For additional commands, e-mail:
>>>>> server-dev-help@james.apache.**org<se...@james.apache.org>
>>>>>
>>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mailets] Proposal: MailetContext enhancement
Posted by Norman Maurer <no...@googlemail.com>.
Yeah I think the latter makes most sense.
Bye
Norman
2011/12/18, Steve Brewin <sb...@synsys.com>:
> 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<sb...@synsys.com>
>>
>>> 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<sb...@synsys.com>
>>>>
>>>> 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-**unsubscribe@james.apache.org<se...@james.apache.org>
>>>>> For additional commands, e-mail: server-dev-help@james.apache.****org<
>>>>> server-dev-help@james.**apache.org<se...@james.apache.org>>
>>>>>
>>>>>
>>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail:
>>> server-dev-unsubscribe@james.**apache.org<se...@james.apache.org>
>>> For additional commands, e-mail:
>>> server-dev-help@james.apache.**org<se...@james.apache.org>
>>>
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mailets] Proposal: MailetContext enhancement
Posted by Norman Maurer <no...@googlemail.com>.
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 <sb...@synsys.com>
> 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<sb...@synsys.com>
>>
>> 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-**unsubscribe@james.apache.org<se...@james.apache.org>
>>> >
>>> For additional commands, e-mail: server-dev-help@james.apache.****org<
>>> server-dev-help@james.**apache.org <se...@james.apache.org>>
>>>
>>>
>>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.**apache.org<se...@james.apache.org>
> For additional commands, e-mail: server-dev-help@james.apache.**org<se...@james.apache.org>
>
>
Re: [mailets] Proposal: MailetContext enhancement
Posted by Steve Brewin <sb...@synsys.com>.
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<sb...@synsys.com>
>
>> 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<se...@james.apache.org>
>> For additional commands, e-mail: server-dev-help@james.apache.**org<se...@james.apache.org>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [mailets] Proposal: MailetContext enhancement
Posted by Norman Maurer <no...@googlemail.com>.
I wonder why you can not use :
MailetContext.sendMail(Mail mail)
Can you give some more details ?
Bye,
Norman
2011/12/17 Steve Brewin <sb...@synsys.com>
> 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<se...@james.apache.org>
> For additional commands, e-mail: server-dev-help@james.apache.**org<se...@james.apache.org>
>
>