james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: Mailet API was RE: Finer Logging Control for Mailets/Matchers
Date Sat, 08 Jun 2002 22:16:12 GMT

I'd vote for ...

interface Maillet {}
interface ConsumingMaillet extends Maillet {

  void processMailRequest(Mail mail) throws MailetException;

interface ModifyingMaillet extends Maillet {

  Mail processMailRequest(Mail mail) throws MailetException;

class Mail {  // value objects
  private final Foo foo;
  private final Bar bar;
  public Mail(Foo foo, Bar bar){
     this.foo = foo;
     this.bar = bar;
  Foo getFoo() { // etc.

I like the immutable Mail bean. All part of the API.

Idon;t like the service() method name :-)

- Paul

>>I'll hope that you have a simple API like :
>>   MailAction mailRequest(MailItem mailItem) throw MailRequestException;
>'s funny you should say that, 'cos I'd like to hear your opinion on this..
>two alternatives;
>a) Mail service(Mail mail) throws MailetException;
>b) void service(Mail mail) throws MailetException;
>the difference being that a returns a Mail which continues through the
>processing, _as__if_ the Mail had been passed by value, and b alters the
>existing message as if it had been passed by refrence (which of course it
>Now I did a lot of C programming, where the refrence approach was the
>conventional one, but in Java the by-value analogy seems to be the expected
>the argument in favour of b is that it is more efficient, and actually
>constrains processors to acting in a linear fashion, by not allowing new
>Mails to be returned.
>Alternatively it might be argued (perhaps by me ;-) that a is the more
>expected/acceptable signature and that anyway there is nothing stopping a
>mailet from replacing the value of Mail mail with a new Mail anyway.
>To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message