james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Mailet API was RE: Finer Logging Control for Mailets/Matchers
Date Sun, 09 Jun 2002 18:33:47 GMT

Yes, TCP/IP is a factor, but I'd be more concerned about GC and memory
issues, not the CPU impact of performing the clone().  However, it is a bit
of a moot point, since the mail object is largely a carrier for
javax.mail.internet.MimeMessage, which is not immutable (more on this in a

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

A "small tree of interfaces" wasn't the issue.  The issue was the loss of
polymorphism.  Although that isn't always a fatal flaw, the loss of
polymorphism is never a good thing, and should be avoided without very good
reason.  That is just good general policy.  In this case, I think that there
are other ways to achieve the desired goal(s).

One simple solution would be something like:

  recipients = matcher.match(matcher.isAllowedChange() ? mail :

  mailet.service(mailet.isAllowedChange() ? mail : mail.duplicate());

(nb: if we care about mail.getState(), we'll have to keep a reference long
enough to check it).  That would create a copy for any matcher or mailet not
allowed to affect a change in the content of the object.

The aforementioned approach says, "we don't know what you might do, and
can't keep track, so we'll simply give you a copy to damage as you might"
but it does not address the general problem of malicious components.  For
example, a malicious mailet involved in industrial espionage could still
quietly queue up copies.

This is a general problem, of which the same could be said of rogue Blocks,
servlets, or any other pluggable component in a pluggable architecture.

The Java answer to this general problem appears to be Java Security.  A
wrapper on mutable components, e.g., MimeMessage, could do security checks
to see if there is permission to affect the desired change.  Likewise, there
could be a permission check to see if a mailet is permitted to post a new
message to a processor queue.  Now the administrator can control exactly
what operations are permitted by a given component.

	--- Noel

-----Original Message-----
From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
Sent: Sunday, June 09, 2002 3:51
To: James Developers List
Subject: Re: Mailet API was RE: Finer Logging Control for


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.


- 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
>contents during processing.  Having to clone something just to make a
>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
>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
>>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>

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