Hi Just a side note: The username/password has been asked several times on the user forum. Maybe we can do some smart thing there as well? Or at least document in the JMS wiki how to set it up, or point in right direction.
Will get back to "any thoughts" later, but I gotta fight with the CAPS now ;) Med venlig hilsen Claus Ibsen ...................................... Silverbullet Skovsgårdsvænget 21 8362 Hørning Tlf. +45 2962 7576 Web: www.silverbullet.dk -----Original Message----- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: 27. august 2008 14:58 To: [email protected] Subject: switching JMS to use transacted mode by default and to auto-default the TrasactionManager... 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
