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
