Return-Path: 
 <users-return-6136-apmail-camel-users-archive=camel.apache.org@camel.apache.org>
Delivered-To: apmail-camel-users-archive@www.apache.org
Received: (qmail 29115 invoked from network); 24 Mar 2009 13:20:19 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3)
  by minotaur.apache.org with SMTP; 24 Mar 2009 13:20:19 -0000
Received: (qmail 83152 invoked by uid 500); 24 Mar 2009 13:20:19 -0000
Delivered-To: apmail-camel-users-archive@camel.apache.org
Received: (qmail 83120 invoked by uid 500); 24 Mar 2009 13:20:19 -0000
Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@camel.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@camel.apache.org>
List-Post: <mailto:users@camel.apache.org>
List-Id: <users.camel.apache.org>
Reply-To: users@camel.apache.org
Delivered-To: mailing list users@camel.apache.org
Received: (qmail 83110 invoked by uid 99); 24 Mar 2009 13:20:19 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Mar 2009 13:20:19 +0000
X-ASF-Spam-Status: No, hits=3.4 required=10.0
	tests=FM_FAKE_HELO_VERIZON,HTML_MESSAGE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [206.46.173.9] (HELO vms173009pub.verizon.net) (206.46.173.9)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 24 Mar 2009 13:20:11 +0000
Received: from [192.168.1.150] ([77.70.60.214]) by vms173009.mailsrvcs.net
 (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit))
 with ESMTPA id <0KH000HQ0ICLSOWP@vms173009.mailsrvcs.net> for
 users@camel.apache.org; Tue, 24 Mar 2009 08:19:35 -0500 (CDT)
Message-id: <49C8DDE5.9020508@attglobal.net>
Date: Tue, 24 Mar 2009 09:19:33 -0400
From: Colin Ruthven <ruthven@attglobal.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21)
 Gecko/20090303 SeaMonkey/1.1.15
MIME-version: 1.0
To: users@camel.apache.org
Subject: Re: Non-Spring Transaction Manager
References: <49C7B384.7040609@attglobal.net>
 <5380c69c0903231125q6ccf7215h6ee93a7335ca07ac@mail.gmail.com>
 <49C7DF43.2010100@attglobal.net>
 <ec6e67fd0903240244je990b50h1ef4067289ec6e5a@mail.gmail.com>
In-reply-to: <ec6e67fd0903240244je990b50h1ef4067289ec6e5a@mail.gmail.com>
Content-type: multipart/alternative;
 boundary=------------080308060904040501060802
X-Virus-Checked: Checked by ClamAV on apache.org

--------------080308060904040501060802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks. That got me further.

Assuming I use JOTM and use it for transaction control within Java, I 
attempted the following applicationContext.xml :

   <context:component-scan base-package="org.apache.camel.spring.produce"/>
   <camel:camelContext id="camel">
   </camel:camelContext>
 
  <bean id="jotm" 
class="org.springframework.transaction.jta.JotmFactoryBean"/>
 
  <bean id="jtaTransactionManager" 
class="org.springframework.transaction.jta.JtaTransactionManager">
       <property name="userTransaction"><ref local="jotm"/></property>
  </bean>

    <bean id="jmsConnectionFactory" 
class="org.apache.activemq.spring.ActiveMQXAConnectionFactory">      
    </bean>
   
    <bean id="jmsComponent" 
class="org.apache.camel.component.jms.JmsComponent">
        <property name="transactionManager"><ref 
local="jtaTransactionManager"/></property>
        <property name="transacted" value="true"/>
        <property name="connectionFactory"><ref 
local="jmsConnectionFactory"/> </property>
    </bean>

I have a unit test successfully sending and receiving to an ActiveMQ 
broker outside the VM.

To that test I created a JOTM TransactionManager, Transaction then 
prefixed the producer.sendBody() with a begin transaction and followed 
the send with a rollback.
The message still gets sent.

By the looks of stdout Spring is finding the JTA and JOTM is starting.

I'm using Camel 1.6 and ActiveMQ 5.2

What am I missing?

Thanks,
Colin

James Strachan wrote:
> 2009/3/23 Colin Ruthven <ruthven@attglobal.net>:
>   
>> I don't specifically have one in mind.
>>
>> In exploring Camel I found that one can perform the basic messaging
>> functions in Java using Camel API's only but got messy with transactions.
>>
>> My preference would be for Camel to expose a JTA. If that transparently
>> invoked Spring TX that would be fine - analogous to the various components
>> wrapping Spring but not exposing it directly in Java.
>>     
>
> BTW you can ignore the Spring IoC stuff if you like and just use Java
> to wire stuff together and populate JNDI - or use Guice or whatever.
>
>
>   
>> What other options exist outside a container (or inside) for transaction
>> support that would work with Camel?
>>     
>
> The JMS component & endpoints relies on the Spring JMS abstractions
> (JmsTemplate and MessageListenerContainer classes) which use Spring
> transactions under the covers. However its pretty trivial to configure
> the JmsComponent to use Spring's JtaTransactionManager then you can do
> whatever you like with JTA and all the JMS endpoints will be
> auto-enlisted in JTA for you.
>
> However one of the main benefits of the spring transactions support
> (other than the proxy/aop/annotation stuff) is that its trivial to
> switch between XA/JTA and  lightweight transactions (e.g. pure JMS
> transactions or pure JDBC transactions) without the J2EE Transaction
> Manager / JCA / XA overhead.
>
>   

--------------080308060904040501060802--