For future reference: the correct link is [1]. There was a typo in the anchor.
[1] * https://issues.apache.org/jira/browse/CAMEL-6108?focusedCommentId=13592471&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13592471 * Regards, *Raúl Kripalani* Enterprise Architect, Open Source Integration specialist, Program Manager | Apache Camel Committer http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk On Tue, Mar 19, 2013 at 4:39 PM, Matt Pavlovich <mattr...@gmail.com> wrote: > Thanks Raul. Added myself as a watcher and I'm available for testing help. > > On Mar 18, 2013, at 8:57 PM, Raul Kripalani <r...@evosent.com> wrote: > > > Hey Matt, > > > > There was some discussion about this topic a few weeks ago in this list. > > You may want to look it up. I think most of us are on the same track. > > > > Take a look at > > > https://issues.apache.org/jira/browse/CAMEL-6108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592471#comment-13592471for > > a proposal. > > > > Raúl. > > > > Sent while on the move > > On 19 Mar 2013 00:38, "Matt Pavlovich" <mattr...@gmail.com> wrote: > > > >> If all goes well with the sjms component conversion, could we drop the > old > >> component completely and rename sjms -> jms? > >> > >> Another request for 3.0: > >> > >> - Convert the http4 component to -> "http" (original http component > >> dropped) > >> > >> Thanks, > >> Matt Pavlovich > >> > >> On Mar 4, 2013, at 2:35 PM, Scott England-Sullivan <sully6...@gmail.com > > > >> wrote: > >> > >>> Should we have a global JIRA ticket for the 3.0 JTA support to track > all > >>> the components this impacts? > >>> > >>> On Thu, Feb 28, 2013 at 12:51 PM, Guillaume Nodet <gno...@gmail.com> > >> wrote: > >>> > >>>> On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan < > >>>> sully6...@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 <ch...@cxtsoftware.com> > >>>>> wrote: > >>>>> > >>>>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <gno...@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 <ch...@cxtsoftware.com > > > >>>>>> wrote: > >>>>>>> > >>>>>>>> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet < > gno...@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 < > >>>> ch...@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: gno...@redhat.com > >>>>>>>>> Web: http://fusesource.com > >>>>>>>>> Blog: http://gnodet.blogspot.com/ > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -- > >>>>>>> ------------------------ > >>>>>>> Guillaume Nodet > >>>>>>> ------------------------ > >>>>>>> Red Hat, Open Source Integration > >>>>>>> > >>>>>>> Email: gno...@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: gno...@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 > >> > >> > >
