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 Sun, 09 Jun 2002 07:51:10 GMT
Noel,

You are dealing with TCP/IP yes.  Including marshalling, it is 1000's of 
times slower than object instantiation yes? Even local loop is 100s of 
times slower.

There is _nothing_ wrong with having a small tree of interfaces for 
Maillet types.

I am only mildly in favour of the immutable parms.  It seems better 
security for the container against the malicious maillet, but as I say 
for this TCP/IP using beast, performance is not a justification for 
avoiding immutable. It also fits well with the AltRMI tool that the 
Avalon team developed (Which I'm guessing that still none of you have 
read up on).  This would allow the concept of a remote Maillet without 
changing or adapting the Maillet API at all.  Then again there is a case 
for having Mail as an interface, and for those Maillets that XML 
declared that they were non-modifying, the setters were disabled in a 
hand-crafted proxy.

Regards,

- Paul

>The processor should only have to know that it is calling a Mailet.
>Consider how this would be called from the processor.  The difference in
>return type means that you have to know what you are calling in order to
>call it.
>
>The Mail is not be immutable, give that the MimeMessage is not immutable.
>Matchers and Mailets are permitted, if not sometimes required, to change the
>contents during processing.  Having to clone something just to make a change
>is not a happy pattern when it comes to performance.
>
>The init() and service() interfaces are part of the general *let pattern.
>
>I do wish, however, that the bean pattern for mutators had been
>
>   Class C { C setProp(T p); }
>
>instead of
>
>   Class C { void setProp(T p); }
>
>but Sun blew that one ages ago.
>
>	--- Noel
>
>-----Original Message-----
>From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
>Sent: Saturday, June 08, 2002 18:16
>To: James Developers List
>Subject: Re: Mailet API was RE: Finer Logging Control for
>Mailets/Matchers
>
>
>Danny,
>
>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;
>>
>>and
>>
>>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
>>has).
>>
>>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
>>way.
>>
>>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.
>>
>>d.
>>    
>>
>
>
>--
>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>


Mime
View raw message