Actually, scrub option 4 - I wouldn't like to loose the current contract
rajdavies wrote: > > great work! I'm impressed by how much has already been done! > > btw - I'm considering putting a unique id on the exchange to support > message store and message history patterns but this would introduce a > problem - where does the unique id come from ? > I guess we have some options: > > 1. the endpoint generates it and sets it on the exchange > 2. the endpoint asks the container for an id and then sets on the > exchange > 3. we return a proxy from the container for the Processor(s) - which > automatically adds on an id and decorates the Exchange with any other > stuff which might be useful > 4. the contract is changed - so the exchange is passed through the > container first - the container routes to the processor(s). > > Being a traditionalist (crusty ;))- I like the last option but are > there other options which might ride the camel better ;) ? > > cheers, > > Rob > > On 20 Mar 2007, at 02:07, James Strachan wrote: > >> On 3/19/07, James Strachan <[EMAIL PROTECTED]> wrote: >>> While hungover and stuck on a train I hacked up a little POJO library >>> I've wanted for a while - an easy way to route stuff around JMS using >>> a simple Java DSL and ultimately for easily creating Enterprise >>> Integration Patterns in pure Java... >>> >>> http://cwiki.apache.org/CAMEL/routes.html >>> http://cwiki.apache.org/CAMEL/eip.html >>> >>> its still very much work in progress though! The basic idea is to >>> use >>> Java rather than XML (shock horror!) for creating routing rules >>> and to >>> use generics to make it easy to work with JMS messages directly or to >>> work with other kinds of message like HTTP, JBI or JAX-WS etc >>> >>> I'm still tinkering with it to get the JMS stuff working nicely. >>> I've >>> kept the JMS stuff separate (in camel-jms) so that the camel-core.jar >>> has minimal dependencies so hopefully we might be able to reuse this >>> library on other projects like ServiceMix and CXF >>> >>> Ultimately I'd like to make it easy to drop JMS routes on the >>> classpath which could be automatically embedded in the broker, or >>> enabled in any Spring XML file to simplify the JMS processing for end >>> users. >>> >>> I'll post more details as things start to settle down... >>> >>> As usual, feedback greatly appreciated! >> >> I've just managed to get the first JMS test case working :) >> >> https://svn.apache.org/repos/asf/activemq/camel/trunk/camel-jms/src/ >> test/java/org/apache/camel/jms/JmsRouteTest.java >> >> which under the covers uses Spring's JmsTemplate for sending and the >> AbstractMessageListenerContainer stuff. >> -- >> >> James >> ------- >> http://radio.weblogs.com/0112098/ > > > -- View this message in context: http://www.nabble.com/-HeadsUp--Camel-library-for-POJO-based-routing...-tf3428742s2354.html#a9567730 Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
