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 "Andrew C. Oliver" <an...@superlinksoftware.com> on 2006/11/18 20:56:11 UTC
Proposed Mailet v2 Interface
package org.apache.mailet;
public interface Mailet {
void create();
void start();
void stop();
void destroy();
Mail service(Mail mail);
}
Main changes I'd like to avoid this holdover from Avalon "Configurable" and
make configuration a matter of injection (so all MailetConfig is removed).
I don't really see the need for the four stage lifecycle but this is
basic CS stuff.
I'm happy to remove create/destroy if there is consensus.
Generally I think Mailets will form chains. It strikes me as a better
model to not assume that the mail object going in is the one that is
ultimately delivered to the next mailet in the chain.
Thoughts?
-Andy
Re: Proposed Mailet v2 Interface
Posted by Danny Angus <da...@gmail.com>.
On 11/20/06, Andrew C. Oliver <ac...@apache.org> wrote:
> You make a good point. Let me think about it. I'm about midway through
> coding up a draft set of annotations and interfaces + sample container
> that I think encodes both your and danny's ideas with some twists of my
> own. Once I've got it to where its read I'll put it up for markup. I
> took danny's mailet-refactorings and hacked it up, tapped a build on it.
Nice one, looking forward to seeing it.
I've been side tracked a bit by work(!).
> when I drop in and out take it as just low QoS
> and not disengagement.
Likewise.
> BTW, slightly off-topic (DSN and the effects of spam using it made me
> wonder). What do you guys think of SPF overall?
It certainly addresses a need, and done it in a sensible way.
<my 2c only, please don't flame me!...>I always expected it to be
swept up in a wave of consilidation that would take the best bits from
all of the related ideas and come up with one sensible, consistent
approach (which everyone expected marid to deliver). However from what
I saw it seemed to me as if M$ handling of PRA IPR killed off a lot of
the good-will that existed between those with alternate proposals, and
those concerned about IPR constraints fell back on SPF.</my 2c>
d.
Re: Proposed Mailet v2 Interface
Posted by "Andrew C. Oliver" <ac...@apache.org>.
I've been thinking about this a lot. This is one area where I'm unsure
that the injection method is optimal just because of formal and de-facto
standardization in this area.
On one hand I *HATE* the way that log4j and java logging handle logging
(especially disappointing is java logging not making the 1.5 support add
varargs). I'd much prefer
String parm = "do not";
logger.log(Log.DEBUG, "I %s like cheese", parm);
(where parm is in a ... varargs
http://java.sun.com/j2se/1.5.0/docs/guide/language/varargs.html) to
allow logging w/o ugly if(logger.debugEnabled()) type statements.
However...Using annotations helps reduce the pain of supporting multiple
versions of things (unlike interfaces annotations do not have to be
resolved by the classloader). Using Java logging removes the issue of
versioning conflicts among multiple mailets. Moreover, a buddy of mine
has written a Log4j adapter that gives the Java logging access to log4j
appenders.
Commons logging makes the problem of versioning conflicts worse. (A-B-C
vs A-B)
So my personal preference is to just state that "use the java logging"
and "mailet container providers will configure it"... For my own
personal code I might add that minor varargs wrapper.
However if injection is sincerely that much more preferred here (to
avoid the 1 line of startup code for logger) then field level injection
is probably preferrable to setter level (and this does not preclude
using Java logging BTW).
import java.util.logging.Logger;
...
@Logger
private Logger;
...
Again my preference isn't really based on any logging frameworks
capabilities (if an adapter were not possible to use Log4j's massive
appender library, I'd feel differently), just that it is much neater to
tack this particular dependency to the JDK rather than to particular
potentially conflicting releases of logging frameworks.
Thoughts?
-Andy
Norman Maurer wrote:
> What about providing diffrent loggin levels for the mailets ? At the
> moment we have only one logging level
>
> bye
> Norman
>
> Danny Angus schrieb:
>
>> On 11/20/06, Andrew C. Oliver <ac...@apache.org> wrote:
>>
>>> You make a good point. Let me think about it. I'm about midway through
>>> coding up a draft set of annotations and interfaces + sample container
>>> that I think encodes both your and danny's ideas with some twists of my
>>> own. Once I've got it to where its read I'll put it up for markup. I
>>> took danny's mailet-refactorings and hacked it up, tapped a build on it.
>>>
>> Nice one, looking forward to seeing it.
>> I've been side tracked a bit by work(!).
>>
>>
>>> when I drop in and out take it as just low QoS
>>> and not disengagement.
>>>
>> Likewise.
>>
>>
>>
>>> BTW, slightly off-topic (DSN and the effects of spam using it made me
>>> wonder). What do you guys think of SPF overall?
>>>
>> It certainly addresses a need, and done it in a sensible way.
>>
>> <my 2c only, please don't flame me!...>I always expected it to be
>> swept up in a wave of consilidation that would take the best bits from
>> all of the related ideas and come up with one sensible, consistent
>> approach (which everyone expected marid to deliver). However from what
>> I saw it seemed to me as if M$ handling of PRA IPR killed off a lot of
>> the good-will that existed between those with alternate proposals, and
>> those concerned about IPR constraints fell back on SPF.</my 2c>
>>
>>
>> d.
>> !EXCUBATOR:1,456174ea53071579895989!
>>
>
>
>
Re: Proposed Mailet v2 Interface
Posted by "Andrew C. Oliver" <ac...@apache.org>.
B does not necessitate A here. I also argue strongly that the mailet
should not have a choice, the administrator should. Generally with most
logging frameworks you do this:
Logger log = Logger.get(this.class.getName());
//"org.foo.mailet.MyMailetImpl"
log-config.xml or similar
<appender name="FOO" class="org.foo.FileAppender">
<arg name="filename">/var/log/output.foo</arg>
</appender>
<category name="org.foo.mailet" level="DEBUG" appender="FOO"/>
This way an administrator can centrally determine what mailets,
packages, even classes are logged where and at what level. He can even
limit it system wide, log them to multiple log files or worse!
This COULD be done with injection very simply (field-level) with the
contract that "mailet container providers will configure the logger with
the mailet.class.getName()" and an annotation:
@org.apache.mailet.annotations.Logger
Logger log;
-Andy
Tom Brown wrote:
> A more flexible approach would be to open up the entire logging system
> to the mailet API. This would allow specific mailets to log to various
> log files, rather than all sharing one common log.
>
> Tom
>
> On 11/20/06, Norman Maurer <nm...@byteaction.de> wrote:
>> What about providing diffrent loggin levels for the mailets ? At the
>> moment we have only one logging level
>>
>> bye
>> Norman
Re: Proposed Mailet v2 Interface
Posted by Stefano Bagnara <ap...@bago.org>.
Tom Brown wrote:
> A more flexible approach would be to open up the entire logging system
> to the mailet API. This would allow specific mailets to log to various
> log files, rather than all sharing one common log.
>
> Tom
In James trunk we already fixed this by making it possible to create a
single log for each mailet as the mailetname is part of the logger
specification.
Anyway I think we should provide a "Logger" interface to the mailets (to
be injected by the container) and add to this Logger interface at least
the most used loggin methods (info/debug/fatal/warn) and so on.
Stefano
> On 11/20/06, Norman Maurer <nm...@byteaction.de> wrote:
>> What about providing diffrent loggin levels for the mailets ? At the
>> moment we have only one logging level
>>
>> bye
>> Norman
>
Re: Proposed Mailet v2 Interface
Posted by Tom Brown <to...@gmail.com>.
A more flexible approach would be to open up the entire logging system
to the mailet API. This would allow specific mailets to log to various
log files, rather than all sharing one common log.
Tom
On 11/20/06, Norman Maurer <nm...@byteaction.de> wrote:
> What about providing diffrent loggin levels for the mailets ? At the
> moment we have only one logging level
>
> bye
> Norman
Re: Proposed Mailet v2 Interface
Posted by Norman Maurer <nm...@byteaction.de>.
What about providing diffrent loggin levels for the mailets ? At the
moment we have only one logging level
bye
Norman
Danny Angus schrieb:
> On 11/20/06, Andrew C. Oliver <ac...@apache.org> wrote:
>> You make a good point. Let me think about it. I'm about midway through
>> coding up a draft set of annotations and interfaces + sample container
>> that I think encodes both your and danny's ideas with some twists of my
>> own. Once I've got it to where its read I'll put it up for markup. I
>> took danny's mailet-refactorings and hacked it up, tapped a build on it.
>
> Nice one, looking forward to seeing it.
> I've been side tracked a bit by work(!).
>
>> when I drop in and out take it as just low QoS
>> and not disengagement.
>
> Likewise.
>
>
>> BTW, slightly off-topic (DSN and the effects of spam using it made me
>> wonder). What do you guys think of SPF overall?
>
> It certainly addresses a need, and done it in a sensible way.
>
> <my 2c only, please don't flame me!...>I always expected it to be
> swept up in a wave of consilidation that would take the best bits from
> all of the related ideas and come up with one sensible, consistent
> approach (which everyone expected marid to deliver). However from what
> I saw it seemed to me as if M$ handling of PRA IPR killed off a lot of
> the good-will that existed between those with alternate proposals, and
> those concerned about IPR constraints fell back on SPF.</my 2c>
>
>
> d.
> !EXCUBATOR:1,456174ea53071579895989!
Re: Proposed Mailet v2 Interface
Posted by "Andrew C. Oliver" <ac...@apache.org>.
You make a good point. Let me think about it. I'm about midway through
coding up a draft set of annotations and interfaces + sample container
that I think encodes both your and danny's ideas with some twists of my
own. Once I've got it to where its read I'll put it up for markup. I
took danny's mailet-refactorings and hacked it up, tapped a build on it.
Its all annotations + injection. I think we will need to spell out some
service contracts as well (destinations, repositories, etc). However
for my first roll I hope to show what I think a new mailet should smell
like. It may not include this particular issue. I kinda think this
concept of an Envelope with status is needed as is some contracts
regarding exceptions.
In doing this though I'm trying to keep not only my group's server and
james but Postfix and similar in mind
Shortly it will be very apparent that I'm doing this while very busy
with other things...so when I drop in and out take it as just low QoS
and not disengagement.
BTW, slightly off-topic (DSN and the effects of spam using it made me
wonder). What do you guys think of SPF overall?
Thanks,
-Andy
Stefano Bagnara wrote:
> What I want is to have tools to implement full DSN support in a mail
> server implementing the mailet apis.
>
> A scenario:
>
> In the MAIL FROM an ID can be specified for the message, for tracking
> purpose: we can put this in the Mail object, but we have to make sure
> we know what happens to that mail and we have to decide wether to keep
> the ID for a cloned mail or not (so the container need control over
> this process).
>
> In the RCPT TO a NOTIFY and an ORCPT can be specified: for each
> recipient you can specify what was the original destination address
> and what kind of notification you want. We can put this in the Mail
> object, again, but we have to make sure that when the mail is
> splitted/forwarded we correctly update this data.
>
> The only solution to this issue I found is to define container methods
> (context methods) to "declare" what kind of processing is done to the
> routing.
>
> As an example after a LocalDelivery mailet the container should be
> able to notify the sender if he requested a NOTIFY=success. with a
> ToRepository it depends: we should ask mailet writer to define the
> result of the processing of that mailet.
>
> I think being able to let implementations to support DSN is a *must*
> for the next Mailet APIs: I'm open to any suggestion/proposal on how
> to make this possible.
>
> Stefano
>
> Andrew C. Oliver wrote:
>>> 2) I think we have to add something better for the routing than Mail
>>> service(Mail mail). We need a way to split a message into multiple
>>> parts and let the container know this happened, we need a way to
>>> bounce a message and let the container this happened, to forward to
>>> a different address and let the container know this, to expand it to
>>> multiple recipient and again let it know to dad.
>> Yes...bounce messages. I have a whole barrel of them from things
>> that scan the net and falsify the reply-to. Yes I know it is in the
>> spec, but generally turning it off should be an option.
>>
>> I'm under convinced that the mail needs to be broken into multiple
>> parts and the container informed (this is should be about queues).
>>
>> MailetChains process Queues (you guys call these Spools)
>> MailetChains post to Queues
>>
>> Any mailet can terminate the chain (by returning null)
>>
>> However I agree that more is needed for status. An idea that has
>> been discussed before on james-dev (some years back) and amongst our
>> group (some time back) was the concept of an envelope. In addition
>> to moving the attributes off of the Mail object (which can instead
>> purely represent the mail), we could add something like
>> terminate(reason) that the container can check to see if it should
>> bounce the mail (by policy).
>> Postfix among others actually have a separate bounce queue. But I
>> think that I prefer the notification "this failed, here's why" and
>> leave it up to the container implementation (again my config will be
>> "eat it" or possibly "eat it unless it has a nice spam rating").
>>
>> -Andy
>
>
Re: Proposed Mailet v2 Interface
Posted by Stefano Bagnara <ap...@bago.org>.
What I want is to have tools to implement full DSN support in a mail
server implementing the mailet apis.
A scenario:
In the MAIL FROM an ID can be specified for the message, for tracking
purpose: we can put this in the Mail object, but we have to make sure we
know what happens to that mail and we have to decide wether to keep the
ID for a cloned mail or not (so the container need control over this
process).
In the RCPT TO a NOTIFY and an ORCPT can be specified: for each
recipient you can specify what was the original destination address and
what kind of notification you want. We can put this in the Mail object,
again, but we have to make sure that when the mail is splitted/forwarded
we correctly update this data.
The only solution to this issue I found is to define container methods
(context methods) to "declare" what kind of processing is done to the
routing.
As an example after a LocalDelivery mailet the container should be able
to notify the sender if he requested a NOTIFY=success. with a
ToRepository it depends: we should ask mailet writer to define the
result of the processing of that mailet.
I think being able to let implementations to support DSN is a *must* for
the next Mailet APIs: I'm open to any suggestion/proposal on how to make
this possible.
Stefano
Andrew C. Oliver wrote:
>> 2) I think we have to add something better for the routing than Mail
>> service(Mail mail). We need a way to split a message into multiple
>> parts and let the container know this happened, we need a way to
>> bounce a message and let the container this happened, to forward to a
>> different address and let the container know this, to expand it to
>> multiple recipient and again let it know to dad.
> Yes...bounce messages. I have a whole barrel of them from things that
> scan the net and falsify the reply-to. Yes I know it is in the spec,
> but generally turning it off should be an option.
>
> I'm under convinced that the mail needs to be broken into multiple parts
> and the container informed (this is should be about queues).
>
> MailetChains process Queues (you guys call these Spools)
> MailetChains post to Queues
>
> Any mailet can terminate the chain (by returning null)
>
> However I agree that more is needed for status. An idea that has been
> discussed before on james-dev (some years back) and amongst our group
> (some time back) was the concept of an envelope. In addition to moving
> the attributes off of the Mail object (which can instead purely
> represent the mail), we could add something like terminate(reason) that
> the container can check to see if it should bounce the mail (by policy).
> Postfix among others actually have a separate bounce queue. But I think
> that I prefer the notification "this failed, here's why" and leave it up
> to the container implementation (again my config will be "eat it" or
> possibly "eat it unless it has a nice spam rating").
>
> -Andy
Re: Proposed Mailet v2 Interface
Posted by "Andrew C. Oliver" <ac...@apache.org>.
Stefano Bagnara wrote:
> 1) Why should it contains create/start/stop/destroy and not the
> configuration method?? if you think that configuration is made by
> injection with no specific interface then why can't the
> start/stop/create/destroy method be called in the same way?
>
Makes sense. In that case the interface can be eliminated entirely in
favor of annotations.
> 2) I think we have to add something better for the routing than Mail
> service(Mail mail). We need a way to split a message into multiple
> parts and let the container know this happened, we need a way to
> bounce a message and let the container this happened, to forward to a
> different address and let the container know this, to expand it to
> multiple recipient and again let it know to dad.
Yes...bounce messages. I have a whole barrel of them from things that
scan the net and falsify the reply-to. Yes I know it is in the spec,
but generally turning it off should be an option.
I'm under convinced that the mail needs to be broken into multiple parts
and the container informed (this is should be about queues).
MailetChains process Queues (you guys call these Spools)
MailetChains post to Queues
Any mailet can terminate the chain (by returning null)
However I agree that more is needed for status. An idea that has been
discussed before on james-dev (some years back) and amongst our group
(some time back) was the concept of an envelope. In addition to moving
the attributes off of the Mail object (which can instead purely
represent the mail), we could add something like terminate(reason) that
the container can check to see if it should bounce the mail (by policy).
Postfix among others actually have a separate bounce queue. But I think
that I prefer the notification "this failed, here's why" and leave it up
to the container implementation (again my config will be "eat it" or
possibly "eat it unless it has a nice spam rating").
-Andy
>
> I don't see anything better than the current mailet apis in this
> interface, sorry.
>
> Stefano
>
> Andrew C. Oliver wrote:
>> package org.apache.mailet;
>>
>> public interface Mailet {
>>
>> void create();
>> void start();
>> void stop();
>> void destroy();
>>
>> Mail service(Mail mail);
>> }
>>
>>
>> Main changes I'd like to avoid this holdover from Avalon
>> "Configurable" and
>> make configuration a matter of injection (so all MailetConfig is
>> removed).
>> I don't really see the need for the four stage lifecycle but this is
>> basic CS stuff. I'm happy to remove create/destroy if there is
>> consensus.
>>
>> Generally I think Mailets will form chains. It strikes me as a
>> better model to not assume that the mail object going in is the one
>> that is ultimately delivered to the next mailet in the chain.
>>
>> Thoughts?
>>
>> -Andy
>>
>>
>
>
Re: Proposed Mailet v2 Interface
Posted by Stefano Bagnara <ap...@bago.org>.
1) Why should it contains create/start/stop/destroy and not the
configuration method?? if you think that configuration is made by
injection with no specific interface then why can't the
start/stop/create/destroy method be called in the same way?
2) I think we have to add something better for the routing than Mail
service(Mail mail). We need a way to split a message into multiple parts
and let the container know this happened, we need a way to bounce a
message and let the container this happened, to forward to a different
address and let the container know this, to expand it to multiple
recipient and again let it know to dad.
I don't see anything better than the current mailet apis in this
interface, sorry.
Stefano
Andrew C. Oliver wrote:
> package org.apache.mailet;
>
> public interface Mailet {
>
> void create();
> void start();
> void stop();
> void destroy();
>
> Mail service(Mail mail);
> }
>
>
> Main changes I'd like to avoid this holdover from Avalon "Configurable" and
> make configuration a matter of injection (so all MailetConfig is removed).
> I don't really see the need for the four stage lifecycle but this is
> basic CS stuff. I'm happy to remove create/destroy if there is consensus.
>
> Generally I think Mailets will form chains. It strikes me as a better
> model to not assume that the mail object going in is the one that is
> ultimately delivered to the next mailet in the chain.
>
> Thoughts?
>
> -Andy
>
>
RE: Proposed Mailet v2 Interface
Posted by "Noel J. Bergman" <no...@devtech.com>.
Andrew C. Oliver wrote:
> Generally I think Mailets will form chains. It strikes me as a better
> model to not assume that the mail object going in is the one that is
> ultimately delivered to the next mailet in the chain.
Any orchestration should be done by an external agent, not "chained" by the
Mailet's themselves. Please review, for example, the LinearProcessor in
JAMES. And that is but one possible type.
I've already written extensively on this topic, but the gist is that a
Processor is a named entity associated with message point (typically a
queue) which represents an optionally transactional, addressable, boundary.
The Processor is the Mailet container, with one or more Matcher/Mailet
entries contained therein.
--- Noel