Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of gnodet@gmail.com designates
 74.125.82.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CANZYW6YkXF649rDLXOc29ezCJ_nJTfcyyU3Y-kkCR8yXt6-1ig@mail.gmail.com>
References: 
 <CAFNO4Hjn6Cv=PP9q8LmPFB_Y4qYC1aBpGW9htyBxp-FJP2UC-Q@mail.gmail.com>
 <CALhQg-ZQeVt5TZpdOT=jHKD1r+o7Y19KTfMKHZ74cryuRRgZdQ@mail.gmail.com>
 <CAFNO4HjjFgYUKfSmEgv-QYWW0pyg87_sL=v8Vmi=iBVWbxYJUg@mail.gmail.com>
 <CAEQV+EFGiaE_F7v2Up2WRS5LCnXvG+k_J4fcR-aF1Ky6svMVyA@mail.gmail.com>
 <CAFNO4HgE3=r+kXTO5GuFAYi1jRrNWywHYGzSqmyBiSh+BjnYpA@mail.gmail.com>
 <CAEQV+EFLh+qqj=hO2EkhMpZzYpp=XqE-4L08anJ7K7AdoJ7dgA@mail.gmail.com>
 <CAFNO4HhxTkGZUNcecszzXxX9Vi50Y2eSa2GNULt_F-2-84-LuA@mail.gmail.com>
 <CANZYW6YkXF649rDLXOc29ezCJ_nJTfcyyU3Y-kkCR8yXt6-1ig@mail.gmail.com>
From: Guillaume Nodet <gnodet@gmail.com>
Date: Thu, 28 Feb 2013 19:51:14 +0100
Message-ID: 
 <CAEQV+EF6AaKbaYjxsjh8CPsy_PF38d1wxrCG9AD6maSpWe+DPA@mail.gmail.com>
Subject: Re: 3.0 Ideas
To: "dev@camel.apache.org" <dev@camel.apache.org>
Content-Type: multipart/alternative; boundary=f46d0418265a41efc604d6cd6195

--f46d0418265a41efc604d6cd6195
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <sully6768@gmail.com
> wrote:

> +1 on core transaction support
>
> Since development on SJMS started I have been reviewing JTA and how to
> implement it as a core support API in Camel.  Adding the capability for a
> single endpoint or even multiple endpoints in a route is somewhat strait
> forward.  Extending the boundary of a transaction across routes and
> contexts for XA is where I get out of my depth.
>
> I am happy to help and use SJMS as the initial component for development
> but I would definitely need some guidance.
>
>
> BTW, SJMS only supports JMS Local Transactions and not JTA at this time.
>  My impression was that the only supported Camel Transaction model was to
> use Spring Transactions Manager with Camel and I am trying to keep SJMS
> provider independent.
>

Yes, and thus we need to have our own transaction model in camel, in order
to be independant from spring and be able to use it with blueprint.


>
>
> On Thu, Feb 28, 2013 at 11:30 AM, Chris Geer <chris@cxtsoftware.com>
> wrote:
>
> > On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <gnodet@gmail.com>
> > wrote:
> >
> > > if you configure spring to use the JtaTransactionManager which inherits
> > > from PlatformTransactionManager, then you'll have the spring
> transaction
> > > layer using JTA.
> > >
> > > I'll give this a try.
> >
> > >
> > >
> > > On Thu, Feb 28, 2013 at 1:22 AM, Chris Geer <chris@cxtsoftware.com>
> > wrote:
> > >
> > > > On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <gnodet@gmail.com>
> > > wrote:
> > > >
> > > > > Getting rid of spring transaction support and implementing our own
> > > layer
> > > > in
> > > > > camel would be a big win, as it's really a big missing feature in
> > > > > blueprint.
> > > > > I'm willing to pay a beer to anyone tackling that in 2.12 ...
> > > > >
> > > > > Btw, what's your need for getting rid of spring transaction ? Is
> that
> > > > also
> > > > > to remove the dependency on spring ? Because that one already
> > supports
> > > > > plain JTA.
> > > > >
> > > >
> > > > My big driver right now is that I can use JTA transactions for
> > everything
> > > > except Camel JMS/ActiveMQ. I'm curious about your statement about it
> > > > already supporting JTA. Looking at the JmsComponent, it takes a
> > > > PlatformTransactionManager (i.e. Spring) not a TransactionManager
> > (JTA).
> > > >
> > > > If I could use a standard transaction manager right now I'd be ok for
> > > now.
> > > > Eventually I'd like to be able to run without spring at all though.
> > > >
> > > > >
> > > > >
> > > > > On Wed, Feb 27, 2013 at 9:50 PM, Chris Geer <chris@cxtsoftware.com
> >
> > > > wrote:
> > > > >
> > > > > > On Wednesday, February 27, 2013, Henryk Konsek wrote:
> > > > > >
> > > > > > > Hi Chris,
> > > > > > >
> > > > > > > > 1) Refactor the JMS Component to use JTA transactions instead
> > of
> > > > > Spring
> > > > > > > > Transactions.
> > > > > > >
> > > > > > > I'm not really sure if we need to include such kind of changes
> in
> > > > > > > Camel 3 roadmap. The idea is good, but can't we just raise Jira
> > > issue
> > > > > > > for it? And implement, even in Camel 2? :)
> > > > > >
> > > > > >
> > > > > > Sure, it could be done in 2.x but 3.0 makes more sense to me
> > because
> > > it
> > > > > > would be a breaking change. An alternative would be to support
> both
> > > JTA
> > > > > > transactions and spring transactions and deprecate spring
> > eventually
> > > > but
> > > > > > that could be a pain. Either way I can create the JIRA.
> > > > > >
> > > > > > >
> > > > > > > Best regards.
> > > > > > >
> > > > > > > --
> > > > > > > Henryk Konsek
> > > > > > > http://henryk-konsek.blogspot.com
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ------------------------
> > > > > Guillaume Nodet
> > > > > ------------------------
> > > > > Red Hat, Open Source Integration
> > > > >
> > > > > Email: gnodet@redhat.com
> > > > > Web: http://fusesource.com
> > > > > Blog: http://gnodet.blogspot.com/
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > > ------------------------
> > > Red Hat, Open Source Integration
> > >
> > > Email: gnodet@redhat.com
> > > Web: http://fusesource.com
> > > Blog: http://gnodet.blogspot.com/
> > >
> >
>
>
>
> --
> --
> Scott England-Sullivan
> Apache Camel Committer
> Principal Consultant / Sr. Architect | Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web:     fusesource.com <http://www.fusesource.com> |
> redhat.com<http://www.redhat.com>
> Blog:     sully6768.blogspot.com
> Twitter: sully6768
>


-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

Email: gnodet@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

--f46d0418265a41efc604d6cd6195--