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 > >
