Quick proposal: Mailet and service dependencies in James server

[Joachim Draeger <jd...@gmx.de>]

Hi!

Although I'm referring to James server I think it is the right list.
James server is somehow our reference costumer. :-)
The details of an implementation should of course be discussed on
server-dev.

I just noticed that we already have designated factories for Mailets and
Matchers!
JamesMatcherLoader and JamesMatcherLoader

I guess it is not too difficult to lookup a xml document for each Mailet
and inject dependencies via setters.
Maybe we could even use a framework which could introduce even more
flexibility. 
This way we wouldn't have to declare the deps redundant in config.xml
when a Mailet is used more than once. (config.xml is also big enough :-)
Default dependencies from xml document could be overridden by directives
in config.xml to have full control.

Joachim

Re: Quick proposal: Mailet and service dependencies in James server

[Stefano Bagnara <ap...@bago.org>]

Hi Joachim,

I would prefer to use standard java 5 annotations for the declarative part.

If a container (James Server) wants to support declaring dependencies 
using an XML descriptor this should be implementation specific.

Either way, even if this is implementation specific, I think it is 
useful to even talk about possible implementations of the api we are 
discussing, otherwise we risk to be too much abstract.

Stefano

Joachim Draeger wrote:
> 
> Hi!
> 
> Although I'm referring to James server I think it is the right list.
> James server is somehow our reference costumer. :-)
> The details of an implementation should of course be discussed on
> server-dev.
> 
> I just noticed that we already have designated factories for Mailets and
> Matchers!
> JamesMatcherLoader and JamesMatcherLoader
> 
> I guess it is not too difficult to lookup a xml document for each Mailet
> and inject dependencies via setters.
> Maybe we could even use a framework which could introduce even more
> flexibility. 
> This way we wouldn't have to declare the deps redundant in config.xml
> when a Mailet is used more than once. (config.xml is also big enough :-)
> Default dependencies from xml document could be overridden by directives
> in config.xml to have full control.
> 
> Joachim

Re: Who implements the Mailet API at the moment?

["Andrew C. Oliver" <ac...@apache.org>]

Alan Williamson wrote:
> Naturally JAMES does, but what other mail servers implement the API?
>
> I know JBoss has their own mail server; but is it Mailet friendly?
>
We have our own design.  We have MailListeners which form chains of Mail 
Listeners.  The project is likely to spin
off from JBoss as I no longer work there and the other committers do not 
wish to work on it at JBoss.
> A quick google search came up with nothing!
>
Humm...you must not have typed something opaque JBoss Mail Server.
> Our own project MailCatcher is the only other one that a developer can 
> download today and integrate with Mailets they have written, 
> historically, for JAMES.
>

Re: Who implements the Mailet API at the moment?

["Andrew C. Oliver" <ac...@apache.org>]

Danny Angus wrote:
>
> The matcher shouldn't modify the content of the mail, but it will
> return a collection of recipients which match the condition. If this
> is < the whole set of recipients it will split the message in two so
> that one has the matched recipients and one has the rest.
> For example if a message is destined for both local and remote
> delivery a copy with local recipients and one with remote is created.
> They *both* continue along the rest of the processing unless they are
> stopped for some reason, the net result is that the mail can move down
> more than one path of processing. This makes sense if you think about
> it.
>
> Original -> Local -> spam check -> virusscan -> local delivery
> Original -> Remote -> add habeas -> add footer -> remote delivery

I don't believe in "shouldn't" with user api design.  If the something 
shouldn't modify the mail then something like:

public interface ImmutableMail {
   String getFoo();
}

public class ImmutableMailImpl implements ImmutableMail {
   private Mail mail;
   public ImmutableMailImpl(Mail mail) {
       this.mail = mail;
   }
}

There are lazy tricks you can do with Proxy to just call methods in the 
interface that constructed it but not outside if
you don't want to do a bridge.  Some things have to be done with deep 
classes and there
are always efficiency compromises, but you get the idea.

-Andy

Re: Who implements the Mailet API at the moment?

[Danny Angus <da...@gmail.com>]

On 11/13/06, Tom Brown <to...@gmail.com> wrote:

Tom, good points, but I wanted to clarify this one particlularly:

> 4) The match(Mail) method of matcher is poorly defined-- Is the Mail
> object modified based on the return from the match method call? If so,
> why is a "matcher" modifying the message? If not, why is a collection
> (rather than a simple boolean) being returned?

The matcher shouldn't modify the content of the mail, but it will
return a collection of recipients which match the condition. If this
is < the whole set of recipients it will split the message in two so
that one has the matched recipients and one has the rest.
For example if a message is destined for both local and remote
delivery a copy with local recipients and one with remote is created.
They *both* continue along the rest of the processing unless they are
stopped for some reason, the net result is that the mail can move down
more than one path of processing. This makes sense if you think about
it.

Original -> Local -> spam check -> virusscan -> local delivery
Original -> Remote -> add habeas -> add footer -> remote delivery

Re: Who implements the Mailet API at the moment?

[Tom Brown <to...@gmail.com>]

Hello everyone,

Before discovering JAMES, I created a custom mail server for the
company I work for. Since then, I've been trying to create the mailets
needed to run our business processes inside of JAMES. The concept of
the mailet API is very good, however, I've run into some limitations
inherent to the API and JAMES implementation:

1) Only rudimentary logging support exists.
2) No support exists for running messages through a pipeline before
officially accepting a message to the server (no mailet-based fast
fail.. Yes, I've seen the other discussions).
3) Access to resources that should be global (such as DNS) is
difficult and limited.
4) The match(Mail) method of matcher is poorly defined-- Is the Mail
object modified based on the return from the match method call? If so,
why is a "matcher" modifying the message? If not, why is a collection
(rather than a simple boolean) being returned?
5) Because the JavaMail API is used, it is difficult to concurrently
process multiple large messages, as the messages seem to exist in
memory. (Streaming the contents of large messages from the disk would
seem to be better in that respect).

I send this in response to this thread as I've considered implementing
the mailet API for my custom mail server. This would allow me to
alleviate many of the difficulties (such as fast fail mailets, global
resource access, and logging).

However, my hope is that many of the limitations I've run into can be
alleviated for future versions of the Mailet API (and JAMES) so that I
don't have to roll my own again.

Thanks,
Tom Brown

On 11/13/06, Andrew C. Oliver <an...@superlinksoftware.com> wrote:
> Stefano Bagnara wrote:
> > I think only James Server and MailCatcher.
> >
> > AFAIK, JBMS does not support mailets.
> >
> > So here we are: a bunch of James Server committers, the MailCatcher
> > developer and Andrew Oliver.
> >
> > I would like to know what hat Andrew wear: are you still interested in
> > Mailet APIs for JBMS or are you interested in Mailet APIs for personal
> > interest?
> For the mail server formerly known as JBMS.  Later on it is likely that
> someone else will replace me in here.  For now you're stuck with me.
>
> -Andy
> >
> > I ask this because I think that we should know each other goals to
> > understand better the requirement for the APIs.
> >
> > Stefano
> >
> > Alan Williamson wrote:
> >> Naturally JAMES does, but what other mail servers implement the API?
> >>
> >> I know JBoss has their own mail server; but is it Mailet friendly?
> >>
> >> A quick google search came up with nothing!
> >>
> >> Our own project MailCatcher is the only other one that a developer
> >> can download today and integrate with Mailets they have written,
> >> historically, for JAMES.
> >
> >
>
>
>

Re: Who implements the Mailet API at the moment?

["Andrew C. Oliver" <an...@superlinksoftware.com>]

Stefano Bagnara wrote:
> I think only James Server and MailCatcher.
>
> AFAIK, JBMS does not support mailets.
>
> So here we are: a bunch of James Server committers, the MailCatcher 
> developer and Andrew Oliver.
>
> I would like to know what hat Andrew wear: are you still interested in 
> Mailet APIs for JBMS or are you interested in Mailet APIs for personal 
> interest?
For the mail server formerly known as JBMS.  Later on it is likely that 
someone else will replace me in here.  For now you're stuck with me.

-Andy
>
> I ask this because I think that we should know each other goals to 
> understand better the requirement for the APIs.
>
> Stefano
>
> Alan Williamson wrote:
>> Naturally JAMES does, but what other mail servers implement the API?
>>
>> I know JBoss has their own mail server; but is it Mailet friendly?
>>
>> A quick google search came up with nothing!
>>
>> Our own project MailCatcher is the only other one that a developer 
>> can download today and integrate with Mailets they have written, 
>> historically, for JAMES.
>
>

Re: Who implements the Mailet API at the moment?

[Stefano Bagnara <ap...@bago.org>]

I think only James Server and MailCatcher.

AFAIK, JBMS does not support mailets.

So here we are: a bunch of James Server committers, the MailCatcher 
developer and Andrew Oliver.

I would like to know what hat Andrew wear: are you still interested in 
Mailet APIs for JBMS or are you interested in Mailet APIs for personal 
interest?

I ask this because I think that we should know each other goals to 
understand better the requirement for the APIs.

Stefano

Alan Williamson wrote:
> Naturally JAMES does, but what other mail servers implement the API?
> 
> I know JBoss has their own mail server; but is it Mailet friendly?
> 
> A quick google search came up with nothing!
> 
> Our own project MailCatcher is the only other one that a developer can 
> download today and integrate with Mailets they have written, 
> historically, for JAMES.

Who implements the Mailet API at the moment?

[Alan Williamson <al...@blog-city.com>]

Naturally JAMES does, but what other mail servers implement the API?

I know JBoss has their own mail server; but is it Mailet friendly?

A quick google search came up with nothing!

Our own project MailCatcher is the only other one that a developer can 
download today and integrate with Mailets they have written, 
historically, for JAMES.

Re: Quick proposal: Mailet and service dependencies in James server

["Andrew C. Oliver" <ac...@apache.org>]

I disagree that this is the right list.  Not to be a stickler but I 
think that
the discussion here should be container agnostic.  I don't really care about
JAMES or how JAMES chooses to implement mailets.  I care about a portable
API that provides a "marketplace" of extensions that work in the 
mailserver of
my choice.  How this should be done in JAMES specifically is a great 
conversation
for the regular JAMES development mailing list.

Joachim Draeger wrote:
> Hi!
>
> Although I'm referring to James server I think it is the right list.
> James server is somehow our reference costumer. :-)
> The details of an implementation should of course be discussed on
> server-dev.
>
> I just noticed that we already have designated factories for Mailets and
> Matchers!
> JamesMatcherLoader and JamesMatcherLoader
>
> I guess it is not too difficult to lookup a xml document for each Mailet
> and inject dependencies via setters.
> Maybe we could even use a framework which could introduce even more
> flexibility. 
> This way we wouldn't have to declare the deps redundant in config.xml
> when a Mailet is used more than once. (config.xml is also big enough :-)
> Default dependencies from xml document could be overridden by directives
> in config.xml to have full control.
>
> Joachim
>
>
>
>
>