james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mario Zsilak" <mario.zsi...@inew-cs.com>
Subject AW: [PROPOSAL] Using Camel as replacement of MailProcessor / SpoolManager
Date Thu, 18 Feb 2010 20:22:23 GMT

I just took a glance at camel.apache.org but I spotted the following

<!-- 	start -->
Apache Camel can be used as a routing and mediation engine for the following

    * ...
    * Apache ActiveMQ which is the most popular and powerful open source
message broker
    * ...
<!-- 	 end 	-->

I guess that means that other message brokers (including commercial ones)
are not supported within Apache Camel?
In that case I would be happy to see some kind of abstraction layer so that
others (like me) can implement their own stuff ...

Apart from my requirements I guess most people don't need these (very nice)
features at all.
However if there is a performance gain, especially when using only 1
server/james-instance, we should go for it.

Kind regards,

>-----Urspr√ľngliche Nachricht-----
>Von: norman.maurer@googlemail.com [mailto:norman.maurer@googlemail.com]
>Im Auftrag von Norman Maurer
>Gesendet: Donnerstag, 18. Februar 2010 16:38
>An: James Developers List
>Betreff: [PROPOSAL] Using Camel as replacement of MailProcessor /
>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
>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
>With using Camel it would be possible (just an example) to load
>balance between routes, throttle processing of low priority routes,
>process mail on other server etc. I think this would push James
>extensibility to a new level, and will allow developers to customize
>james more easy.
>To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>For additional commands, e-mail: server-dev-help@james.apache.org

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

View raw message