I've been pondering about the use of JMS and transactions. We've always tried to follow the convention over configuration maxim with Camel; so things should do what you expect without having to configure everything.
So the route <camelContext xmlns="http://activemq.apache.org/camel/schema/spring";> <route> <from uri="activemq:A"/> <to uri="activemq:B"/> <to uri="activemq:C"/> <to uri="activemq:D"/> </route> </camelContext> should route from the ActiveMQ queue A to queues B, C, D without any other configuration if you want to use the defaults (such as the message broker is on localhost on the usual port of 61616. However this doesn't use JMS transactions and spring declarative transactions by default; you've gotta configure the ActiveMQ component with transacted=true along with a transaction manager etc. So I'm wondering for 1.5.0 of Camel if we made 2 subtle changes... * JMS component defaults to transacted by default * JMS component has a lazyCreateTransactionManager flag which defaults to true * if transacted and lazyCreateTransactionManager and there is no transactionManager configured, default to using the Spring JmsTransactionManager Then we'd be using spring transactions by default without the user having to write reams of spring.xml stuff and it'd generally do the right thing. Folks not keen on the 'magic' of convention over configuration could disable this option - as well as using JMS in a non-transacted mode as well. I guess the only real change folks would notice is that things would be transacted by default unless explicitly configured - which might trip some folks up at first. Part of the motivation for this is that its so easy to mess up the configuration of the Spring transaction manager when using Camel; as the Spring JMS transaction manager needs the exact connectionFactory used as a property; so you've gotta create the JMS component, a JMS connection factory and a JMS transaction manager as 3 separate beans and wire them together just so - which becomes even more harder and error prone if you add a JMS pool proxy or a User/Password proxy connection factory and so forth. i.e. I wanted to make it really simple to do the common stuff. I guess we might decide to back off from making the JMS component be transacted by default - but could still use the other changes (so if transacted, we do the right thing). Thoughts? -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://open.iona.com
