Hi Stefano, comments inside...
2010/2/19 Stefano Bagnara <[email protected]>: > 2010/2/18 Norman Maurer <[email protected]>: >> 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: > http://markmail.org/message/vzzmwm3kdv66r3ce > (expecially last senteces). Thx for the pointer to the archives.. > >> 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 > repositories). Not quite right. I would remove the LinearProcessor and StateAwareProcessorList at all. Let me outline the idea a bit more: I would just parse the spoolmanager.xml and create routes per processor via the RouteBuilder class. So it would be one Route per processor. Which processor to use will be detect by check the Camel message header. So I would write some kind of Camel Processor Mailet wrapper to call the mailet, and a Camel Splitter to split the Mail for the Matcher stuff. They Mail objects will get "injected" in the Camel route by an SpoolRepositoryConsumer. The Consumer will fire the Mail to the Route when the spoolRepository.accept() return a Mail object. > > 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). I agree this would be the "final" solution. I just want todo the refactoring step by step to get a better overview and idea about it. Replace the SpoolRepositoryConsumer with something else should be really easy once the rest is in place.. > > 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). +1 > > 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). > True enough.. But I think the KISS principal is the way to go for now.. We can refactor it later to make it more performant. > 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 :-) > > Stefano > > --------------------------------------------------------------------- Thx for you comments.. Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
