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 James/Cocoon integration
Date Thu, 10 Jul 2003 23:56:41 GMT
> > > is there a way to transform XML marked-up email to a standardized
> > > format?

> > The nice way to do that would be to include a Cocoon pipeline into
> > I'd love to see that happen.

> Do you want a cocoon pipeline for an example integration?

Absolutely.  :-)

> I just asked on cocoon-dev if anything exists and received one response
> from a committer, so far, saying they haven't heard of anything.

The topic came up in the past
ache.org&msgId=591219), but I don't believe that anyone has worked on it.

> Do you have any basic instructions on how this could be integrated?
> Is it a mailet? Processor?

Others may feel differently, but my thought is that it would be best to make
it a processor within James, and not a mailet.  A mailet is portable, but
Cocoon is already an Avalon technology consumer, has fairly robust interest
in XML configuration, has its own notion of a pipeline, etc.  An
introduction to internals might help to explain my reaosning.

Both processor and mailet have similar entry points:

    public void Processor.service(MailImpl mail) throws MessagingException;
    public void Mailet.service(Mail mail) throws MessagingException;

MailImpl is a James-specific subclass of the generic Mail class.  Mail
represents the SMTP envelope and other server-related attributes, and has a
reference to the JavaMail Message.  Processor.service() is called by
JamesSpoolManager.process(), and calls the matcher and mailet entry points
accordingly, e.g., LinearProcessor maintains a linear list of matcher/mailet
pairs, and calls match/service.

The responsibilities are:

   JamesSpoolManager: retrieve from spool, call service, remove GHOST from
   Processor: Move message through a process.  Handle exceptions
              that happen during matcher/mailet processing.  If
              message "state" changes, re-spool message for the
              new state.
   Mailet: process a message.  Can set message state (new queue)
           and/or send new message(s).

The spool manager is the queue interface.  It is a pull consumer.  Processor
and Mailet are synchronous push consumers.  Processors are 1:1 with virtual,
named, queues.  Mailets are embedded within processors, and gated by

Cocoon has its own pipeline, with its own filtering and processing notions.
I don't believe that it makes sense to embed Cocoon inside of a Mailet.
Instead, I believe that what we do is implement the class attribute for the
processor element, and have a Cocoon processor, e.g.,

  <processor name="prepareMailing"

A Cocoon processor would have full access to Avalon services, classloaders,
etc.  Mailets will be more restricted in what they can do, and what classes
they can access.

A Road Map would be to refactor LinearProcessor into an interface, generic
base class, and specialized LinearProcessor implementation; and add support
for the class attribute.  We would need someone fluent in Cocoon to work the
Cocoon pieces and sample application(s).

It also seems to me that we'd need an XML mapping for an RFC 2822/2045
message, e.g., XMTP (http://www.openhealth.org/xmtp/XMTP1.0.html), for which
there is a Java implementation (http://www.openhealth.org/xmtp/).  As I
understand Cocoon, we'd need an XMTPGenerator (MIME -> SAX Events) and
XMTPSerializer (SAX Events -> MIME).

	--- Noel

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message