james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [PROPOSAL] Using Camel as replacement of MailProcessor / SpoolManager
Date Fri, 19 Feb 2010 05:56:43 GMT
2010/2/18 Norman Maurer <norman@apache.org>:
> Hi all,
> in the past Stefano told me about his Idea of using camel within james
> (it was just an idea and he had no closer look yet). The last days I
> did some research about camel (camel.apache.org) and I think he is
> right.

To be true the idea was not mine, but from James Strachan:
(expecially last senteces).

> So me plan is:
> * Write a Consumer for our SpoolRepository which would fire of an
> exchange object when a mail object is ready for processing
> * Write a RouteBuilder which will create a route for every configured
> processor  and so replace the MailProcessor stuff at all. The route
> would just to the Matcher, Mailet processing

IIUC you are trying to keep using the current repository
implementation but use camel for routing. This sounds like an
intermediate steps, not sure it's easier (as I never had the time to
investigate on Camel internals). IIUC in your plan you keep using our
spoolmanager xml definition to describe how processors are and then
use camel as an alternative implementation of the "LinearProcessor"
(and you would still use the StateAwareProcessorList and our

The original idea was to simply replace the whole spooling and
SpoolManager with a Camel based component. This would mean dropping
the SpoolRepository interface at all and just use Camel Transport
(activemq/JMS as we probably want persistent queues).

MailServer and MailetContext services then would change to send the
message to Camel or maybe we should change the 2 services with a
simpler service send(Mail/Envelope/Exchange message,
String/URL/Address destination).

As a POC this could work but to be production ready we'll have to also
make the envelope/message split and (like Robert say in his reply)
stream the message content to some storage and only route around the
envelope (the main issue here is reference counting when we duplicate
the envelope as this happens a lot in james).

Take this only as "brainstorming", if you already have a clear idea on
the plan go ahead with your plan: we need some real experience with
camel to see if it really is as good as it sounds :-)


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

View raw message