You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Scott England-Sullivan <su...@gmail.com> on 2013/03/04 20:35:09 UTC
Re: 3.0 Ideas
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 <gn...@gmail.com> wrote:
> 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 <ch...@cxtsoftware.com>
> > wrote:
> >
> > > On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <gn...@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 <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/
>
--
--
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
Re: 3.0 Ideas
Posted by Raul Kripalani <ra...@evosent.com>.
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 <ma...@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 <ra...@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" <ma...@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 <sully6768@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 <gn...@gmail.com>
> >> wrote:
> >>>
> >>>> 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 <ch...@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/
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> --
> >>> 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
> >>
> >>
>
>
Re: 3.0 Ideas
Posted by Matt Pavlovich <ma...@gmail.com>.
Thanks Raul. Added myself as a watcher and I'm available for testing help.
On Mar 18, 2013, at 8:57 PM, Raul Kripalani <ra...@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" <ma...@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 <su...@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 <gn...@gmail.com>
>> wrote:
>>>
>>>> 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 <ch...@cxtsoftware.com>
>>>>> wrote:
>>>>>
>>>>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <gn...@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 <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/
>>>>
>>>
>>>
>>>
>>> --
>>> --
>>> 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
>>
>>
Re: 3.0 Ideas
Posted by Raul Kripalani <ra...@evosent.com>.
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" <ma...@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 <su...@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 <gn...@gmail.com>
> wrote:
> >
> >> 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 <ch...@cxtsoftware.com>
> >>> wrote:
> >>>
> >>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <gn...@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 <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/
> >>
> >
> >
> >
> > --
> > --
> > 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
>
>
Re: 3.0 Ideas
Posted by Hadrian Zbarcea <hz...@gmail.com>.
This has been mentioned a few times, but no agreement was reached.
Actually we should drop the whole MEP as it makes little to no sense. It
could be a hint at best. For me the rationale has little to do with JBI.
The MEP only makes sense for an Endpoint (i.e. Producer or Consumer) but
not for the Route. We might want to keep it as a header for edge cases
like content (header) based routing, although there are a few other ways
to solve that.
My $0.02,
Hadrian
On 04/03/2013 02:58 PM, Chris Geer wrote:
> Just to throw out some other clean-up ideas for Camel 3.0.
>
> I came across this thread here recently [1] talking about exchange patterns
> and the history of camel. Now that JBI is essentially dead, does it make
> sense to use Camel 3.0 to cleanup unused ties back to JBI? For example, get
> rid of the exchange patterns that Camel doesn't really support (OutIn...).
>
> Chris
>
> [1] http://camel.465427.n5.nabble.com/Camel-Exchange-Patters-td2836060.html
>
>
> On Wed, Apr 3, 2013 at 3:16 AM, Marco Westermann <Ma...@gmx.de>wrote:
>
>> Hi Gert,
>>
>> just commented the jira,
>>
>> regards, Marco
>>
>> Am 29.03.2013 12:05, schrieb Gert Vanthienen:
>>
>> Hey Marco,
>>>
>>> Just noticed your remark about the Exception you got when running
>>> things in ServiceMix and I raised JIRA
>>> https://issues.apache.org/**jira/browse/SMX4-1423<https://issues.apache.org/jira/browse/SMX4-1423>to ensure we look into
>>> this before doing the next release. The basic example I tried worked
>>> fine, but that was only exposing a web service and not calling an
>>> external service. If you have a moment, it would be good if you could
>>> add a comment to the JIRA issue explaining how we can reproduce your
>>> problem?
>>>
>>> Thanks in advance,
>>>
>>> Gert
>>>
>>>
>>> On Thu, Mar 28, 2013 at 4:21 PM, Marco Westermann <Ma...@gmx.de>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I use camel for more that one year now and it is actual great for
>>>> integration questions. One thing that I always mess around with is
>>>> calling
>>>> external web services (soap in general). And IMHO this is a central use
>>>> case
>>>> for soa / integration purposes. I received the impression that this
>>>> central
>>>> use case has not the weight it should have in an integegration framework
>>>> like camel. E.g. most examples with camel and cxf shows how to expose a
>>>> web
>>>> service, not how to consume one; there are maven archtypes which create
>>>> new
>>>> projects again only for exposing a service - there is no archtype for
>>>> consuming one. Even the camel in action book mostly covers cxf to use as
>>>> a
>>>> provider. So I think this should be made much easier with much more
>>>> examples. (or that easy that no example is neccessary) If you know
>>>> openesb
>>>> / glassfish esb there it is a matter of drag and drop a wsdl to the
>>>> project,
>>>> use an operation as endpoint (which you can use from a drop down box) and
>>>> specify the message-mapping (all is supported by easy clicky clicky)
>>>>
>>>> Don't get me wrong. I really like camel very much, but I always have some
>>>> problems with:
>>>>
>>>> * what component should I use (http, cxf, spring-ws) I think cxf should
>>>> be
>>>> the standard but should be easier to use
>>>> * most of my camel routes run in smx. my acutal problem in smx 4.5 (which
>>>> seems to be an osgi-problem) is that I get an exception which says that
>>>> no
>>>> org.apache.cxf.jaxws.spi.**ProviderImpl could be found. And I already
>>>> tried 4
>>>> hours to fix this issue without success..
>>>>
>>>> These hurdles makes it to a costly task to implement a route which should
>>>> call a service. IMHO this should not take longer that 5 mins to implement
>>>> that if you already have a wsdl for the service.
>>>>
>>>>
>>>> I hope my suggestions are understandable / useful.
>>>>
>>>> I which you all Happy Easter,
>>>>
>>>> regards,
>>>>
>>>> Marco Westermann
>>>>
>>>>
>>>>
>>
>
Re: 3.0 Ideas
Posted by Chris Geer <ch...@cxtsoftware.com>.
Just to throw out some other clean-up ideas for Camel 3.0.
I came across this thread here recently [1] talking about exchange patterns
and the history of camel. Now that JBI is essentially dead, does it make
sense to use Camel 3.0 to cleanup unused ties back to JBI? For example, get
rid of the exchange patterns that Camel doesn't really support (OutIn...).
Chris
[1] http://camel.465427.n5.nabble.com/Camel-Exchange-Patters-td2836060.html
On Wed, Apr 3, 2013 at 3:16 AM, Marco Westermann <Ma...@gmx.de>wrote:
> Hi Gert,
>
> just commented the jira,
>
> regards, Marco
>
> Am 29.03.2013 12:05, schrieb Gert Vanthienen:
>
> Hey Marco,
>>
>> Just noticed your remark about the Exception you got when running
>> things in ServiceMix and I raised JIRA
>> https://issues.apache.org/**jira/browse/SMX4-1423<https://issues.apache.org/jira/browse/SMX4-1423>to ensure we look into
>> this before doing the next release. The basic example I tried worked
>> fine, but that was only exposing a web service and not calling an
>> external service. If you have a moment, it would be good if you could
>> add a comment to the JIRA issue explaining how we can reproduce your
>> problem?
>>
>> Thanks in advance,
>>
>> Gert
>>
>>
>> On Thu, Mar 28, 2013 at 4:21 PM, Marco Westermann <Ma...@gmx.de>
>> wrote:
>>
>>> Hi,
>>>
>>> I use camel for more that one year now and it is actual great for
>>> integration questions. One thing that I always mess around with is
>>> calling
>>> external web services (soap in general). And IMHO this is a central use
>>> case
>>> for soa / integration purposes. I received the impression that this
>>> central
>>> use case has not the weight it should have in an integegration framework
>>> like camel. E.g. most examples with camel and cxf shows how to expose a
>>> web
>>> service, not how to consume one; there are maven archtypes which create
>>> new
>>> projects again only for exposing a service - there is no archtype for
>>> consuming one. Even the camel in action book mostly covers cxf to use as
>>> a
>>> provider. So I think this should be made much easier with much more
>>> examples. (or that easy that no example is neccessary) If you know
>>> openesb
>>> / glassfish esb there it is a matter of drag and drop a wsdl to the
>>> project,
>>> use an operation as endpoint (which you can use from a drop down box) and
>>> specify the message-mapping (all is supported by easy clicky clicky)
>>>
>>> Don't get me wrong. I really like camel very much, but I always have some
>>> problems with:
>>>
>>> * what component should I use (http, cxf, spring-ws) I think cxf should
>>> be
>>> the standard but should be easier to use
>>> * most of my camel routes run in smx. my acutal problem in smx 4.5 (which
>>> seems to be an osgi-problem) is that I get an exception which says that
>>> no
>>> org.apache.cxf.jaxws.spi.**ProviderImpl could be found. And I already
>>> tried 4
>>> hours to fix this issue without success..
>>>
>>> These hurdles makes it to a costly task to implement a route which should
>>> call a service. IMHO this should not take longer that 5 mins to implement
>>> that if you already have a wsdl for the service.
>>>
>>>
>>> I hope my suggestions are understandable / useful.
>>>
>>> I which you all Happy Easter,
>>>
>>> regards,
>>>
>>> Marco Westermann
>>>
>>>
>>>
>
Re: 3.0 Ideas
Posted by Marco Westermann <Ma...@gmx.de>.
Hi Gert,
just commented the jira,
regards, Marco
Am 29.03.2013 12:05, schrieb Gert Vanthienen:
> Hey Marco,
>
> Just noticed your remark about the Exception you got when running
> things in ServiceMix and I raised JIRA
> https://issues.apache.org/jira/browse/SMX4-1423 to ensure we look into
> this before doing the next release. The basic example I tried worked
> fine, but that was only exposing a web service and not calling an
> external service. If you have a moment, it would be good if you could
> add a comment to the JIRA issue explaining how we can reproduce your
> problem?
>
> Thanks in advance,
>
> Gert
>
>
> On Thu, Mar 28, 2013 at 4:21 PM, Marco Westermann <Ma...@gmx.de> wrote:
>> Hi,
>>
>> I use camel for more that one year now and it is actual great for
>> integration questions. One thing that I always mess around with is calling
>> external web services (soap in general). And IMHO this is a central use case
>> for soa / integration purposes. I received the impression that this central
>> use case has not the weight it should have in an integegration framework
>> like camel. E.g. most examples with camel and cxf shows how to expose a web
>> service, not how to consume one; there are maven archtypes which create new
>> projects again only for exposing a service - there is no archtype for
>> consuming one. Even the camel in action book mostly covers cxf to use as a
>> provider. So I think this should be made much easier with much more
>> examples. (or that easy that no example is neccessary) If you know openesb
>> / glassfish esb there it is a matter of drag and drop a wsdl to the project,
>> use an operation as endpoint (which you can use from a drop down box) and
>> specify the message-mapping (all is supported by easy clicky clicky)
>>
>> Don't get me wrong. I really like camel very much, but I always have some
>> problems with:
>>
>> * what component should I use (http, cxf, spring-ws) I think cxf should be
>> the standard but should be easier to use
>> * most of my camel routes run in smx. my acutal problem in smx 4.5 (which
>> seems to be an osgi-problem) is that I get an exception which says that no
>> org.apache.cxf.jaxws.spi.ProviderImpl could be found. And I already tried 4
>> hours to fix this issue without success..
>>
>> These hurdles makes it to a costly task to implement a route which should
>> call a service. IMHO this should not take longer that 5 mins to implement
>> that if you already have a wsdl for the service.
>>
>>
>> I hope my suggestions are understandable / useful.
>>
>> I which you all Happy Easter,
>>
>> regards,
>>
>> Marco Westermann
>>
>>
Re: 3.0 Ideas
Posted by Gert Vanthienen <ge...@gmail.com>.
Hey Marco,
Just noticed your remark about the Exception you got when running
things in ServiceMix and I raised JIRA
https://issues.apache.org/jira/browse/SMX4-1423 to ensure we look into
this before doing the next release. The basic example I tried worked
fine, but that was only exposing a web service and not calling an
external service. If you have a moment, it would be good if you could
add a comment to the JIRA issue explaining how we can reproduce your
problem?
Thanks in advance,
Gert
On Thu, Mar 28, 2013 at 4:21 PM, Marco Westermann <Ma...@gmx.de> wrote:
> Hi,
>
> I use camel for more that one year now and it is actual great for
> integration questions. One thing that I always mess around with is calling
> external web services (soap in general). And IMHO this is a central use case
> for soa / integration purposes. I received the impression that this central
> use case has not the weight it should have in an integegration framework
> like camel. E.g. most examples with camel and cxf shows how to expose a web
> service, not how to consume one; there are maven archtypes which create new
> projects again only for exposing a service - there is no archtype for
> consuming one. Even the camel in action book mostly covers cxf to use as a
> provider. So I think this should be made much easier with much more
> examples. (or that easy that no example is neccessary) If you know openesb
> / glassfish esb there it is a matter of drag and drop a wsdl to the project,
> use an operation as endpoint (which you can use from a drop down box) and
> specify the message-mapping (all is supported by easy clicky clicky)
>
> Don't get me wrong. I really like camel very much, but I always have some
> problems with:
>
> * what component should I use (http, cxf, spring-ws) I think cxf should be
> the standard but should be easier to use
> * most of my camel routes run in smx. my acutal problem in smx 4.5 (which
> seems to be an osgi-problem) is that I get an exception which says that no
> org.apache.cxf.jaxws.spi.ProviderImpl could be found. And I already tried 4
> hours to fix this issue without success..
>
> These hurdles makes it to a costly task to implement a route which should
> call a service. IMHO this should not take longer that 5 mins to implement
> that if you already have a wsdl for the service.
>
>
> I hope my suggestions are understandable / useful.
>
> I which you all Happy Easter,
>
> regards,
>
> Marco Westermann
>
>
Re: 3.0 Ideas
Posted by Marco Westermann <Ma...@gmx.de>.
Hi,
I use camel for more that one year now and it is actual great for
integration questions. One thing that I always mess around with is
calling external web services (soap in general). And IMHO this is a
central use case for soa / integration purposes. I received the
impression that this central use case has not the weight it should have
in an integegration framework like camel. E.g. most examples with camel
and cxf shows how to expose a web service, not how to consume one; there
are maven archtypes which create new projects again only for exposing a
service - there is no archtype for consuming one. Even the camel in
action book mostly covers cxf to use as a provider. So I think this
should be made much easier with much more examples. (or that easy that
no example is neccessary) If you know openesb / glassfish esb there it
is a matter of drag and drop a wsdl to the project, use an operation as
endpoint (which you can use from a drop down box) and specify the
message-mapping (all is supported by easy clicky clicky)
Don't get me wrong. I really like camel very much, but I always have
some problems with:
* what component should I use (http, cxf, spring-ws) I think cxf should
be the standard but should be easier to use
* most of my camel routes run in smx. my acutal problem in smx 4.5
(which seems to be an osgi-problem) is that I get an exception which
says that no org.apache.cxf.jaxws.spi.ProviderImpl could be found. And I
already tried 4 hours to fix this issue without success..
These hurdles makes it to a costly task to implement a route which
should call a service. IMHO this should not take longer that 5 mins to
implement that if you already have a wsdl for the service.
I hope my suggestions are understandable / useful.
I which you all Happy Easter,
regards,
Marco Westermann
Re: 3.0 Ideas
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Mar 24, 2013 at 5:23 PM, Henryk Konsek <he...@gmail.com> wrote:
>> We already have a removeHeaders() DSL [1]
>
> Wow, indeed we got it. :)
>
> We definitely need to improve our documentation in this regards. I
> feel pretty familiar with Camel wiki and haven't notice this one :) .
> I guess that the majority of our users don't know about removeHeaders
> option as well.
>
> I'll try to edit wiki to make this option more visible. Not sure when however.
>
A good idea is to use the google search box on the front page. And
type in the name of the DSL and read the links. That is a good way to
find documentation.
Also we have 2 FAQs about this. The other is
http://camel.apache.org/how-to-avoid-sending-some-or-all-message-headers.html
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: 3.0 Ideas
Posted by Henryk Konsek <he...@gmail.com>.
> Improving docs is always appreciated. For example at any time fell
> free to add FAQ entries for stuff that you feel is good knowledge for
> others.
Actually I think that this kind of information should be easier to
find while browsing the Java DSL wiki.
For me, the example of perfect documentation is Spring Reference [1].
When I navigate to Spring AOP part of it, I can be sure that I'll find
there all information regarding Spring AOP (which is pretty logical).
In Camel we tend to spread the Camel knowledge between documentation,
FAQ and JavaDoc.
> A good idea is to use the google search box on the front page. And
> type in the name of the DSL and read the links. That is a good way to
> find documentation.
This approach works perfect if you know what you're searching for. If
user is unaware of the existence of the given feature, she won't run
search against it.
Best regards.
[1] http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: 3.0 Ideas
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Mar 25, 2013 at 11:10 PM, Raul Kripalani <ra...@evosent.com> wrote:
> Hi Claus,
>
> Responses inline.
>
> 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 Mon, Mar 25, 2013 at 4:43 PM, Claus Ibsen <cl...@gmail.com> wrote:
>
>> On Sun, Mar 24, 2013 at 5:23 PM, Henryk Konsek <he...@gmail.com> wrote:
>> >> We already have a removeHeaders() DSL [1]
>> >
>> > Wow, indeed we got it. :)
>> >
>> > We definitely need to improve our documentation in this regards. I
>> > feel pretty familiar with Camel wiki and haven't notice this one :) .
>> > I guess that the majority of our users don't know about removeHeaders
>> > option as well.
>> >
>> > I'll try to edit wiki to make this option more visible. Not sure when
>> however.
>> >
>>
>> Do you guys read the javadoc of the Java DSL? We have java doc on the
>> DSL where we provide a little information.
>>
>
> I know you aren't referring to me, but I'm sure that all dev@ posters have
> read the Javadocs ;)
>
>
>> We could enhance this javadoc and add more links to more details at
>> the Camel web site. For example in the case of removeHeader DSL we
>> could refer to these FAQ's etc.
>>
>
> You're just asking for broken links in the Javadocs! We can't guarantee
> that a FAQ entry will be alive for the lifetime of a Camel release in the
> Maven repos, i.e. forever.
>
The FAQ entries have been online for 6 years and they have not been broken.
The links is static and stable.
For example this old FAQ
http://camel.apache.org/can-i-use-camel-on-java-14.html
We should give the end users hints and references where they can read
more material.
If they use Java DSL then javadoc is the standard in Java, how to
document an API.
We already have javadoc for the Java DSL. It would be easy to add some
more material in these javadocs,
and as well point the users to FAQs, and the EIP docs etc.
> IMHO we should focus on restructuring the website (see below). Let's fix
> the base problem instead of patching here and there and creating a jumble
> of unmaintainable links throughout time.
>
> Improving docs is always appreciated. For example at any time fell
>> free to add FAQ entries for stuff that you feel is good knowledge for
>> others.
>
I was maybe not to precise in the mail. I was suggesting to add FAQs
for stuff that you
see as common questions that people keep asking about in these forums.
And you are allowed to use what you have between your ears, and add /
improve the docs.
So if one of the EIPs could be improved, then for sure fell free to
work on that doc page as well.
Frankly its not very many of the Camel team members who help with the
docs. I don't blame them.
Its probably more fun to work on the code.
Another way to help our end users is to build new examples, as often
an example is a great way of learning stuff.
Or even add a little new cookbook snippet about how to do X
http://camel.apache.org/cookbook
>
> I beg to differ. FAQ-centric documentation is hell for everyone:
> committers, users, evaluators, newbies, etc. Imagine if Wikipedia was a
> collection of a bunch of questions like "When was the GMT timezone
> created?", "How tall can a Giraffe be?", etc. You get me.
>
First I think your wikipedia analogy is off - And I do NOT get you.
The first thing I do on wikipedia, is to type in a key word(s) to
search for links what I am looking for. That is similar to what you
can do on the Camel site with the "search box" Whether those "hits"
refer to a FAQ, or other places does not matter. Its the fact we have
hit on links where the user can read more.
Frankly all/most OSS projects have FAQs (and with more content we do).
See for example Apache Tomcat
http://wiki.apache.org/tomcat/FAQ
http://wiki.apache.org/tomcat/HowTo
The FAQ should not be the single-source of information. But where we
can have a short description and point the readers to other pages
where he/she can find more material. So its just a help for the users.
And also a way of telling users what are some of the common "stuff"
that people have with Camel.
Frankly you guys should try look at our FAQ, there may be stuff you do not know.
And also can inspire you to say .. ah I see this problem/question
alot, but I cannot find a FAQ for it. Let me add that.
> We need better documentation structure. I shared some ideas on overhauling
> component pages in May 2012 [1] - before I became a committer. But the need
> for a modern website keeps haunting me time after time, as I see other
> sites like Apache Cordova [2], Apache Shiro [3], etc. Even the Apache ODE
> project [4] – which hasn't seen a release in 2 years – has a refurbished
> website!
>
> All in all: new website, new documentation structure.
>
Well guess what. Of all the zillion Camel 3.0 ideas, you are the only
one raising that task.
Again most of the Camel committers want to hack on the camel-core code.
Dont take me wrong. I would like a revamped website, and top notch
documentation.
But that is very hard to do, and takes a long time.
There is a ton of Camel documentation. Its just a mix between
- Camel wiki pages
- 3rd party blogs, articles, tutorials (links from our articles page)
- Camel in Action book
- Video presentations
- etc
> I guess I'm asking to reignite the discussion here: [5].
>
> [1]
> http://camel.465427.n5.nabble.com/Improving-the-Documentation-Articles-Presentations-etc-tp5711559p5713170.html
> [2] http://cordova.apache.org/
> [3] http://shiro.apache.org/
> [4] http://ode.apache.org/
> [5] http://camel.apache.org/site-update-ideas.html
>
>
>>
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Email: cibsen@redhat.com
>> Web: http://fusesource.com
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
>>
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: 3.0 Ideas
Posted by James Strachan <ja...@gmail.com>.
On 27 March 2013 07:03, Claus Ibsen <cl...@gmail.com> wrote:
> On Tue, Mar 26, 2013 at 5:15 PM, Henryk Konsek <he...@gmail.com> wrote:
>>>> Do you guys read the javadoc of the Java DSL? We have java doc on the
>>>> DSL where we provide a little information.
>>> I know you aren't referring to me, but I'm sure that all dev@ posters have
>>> read the Javadocs ;)
>>
>> We want users to learn about DSL from Javadoc? IMHO reference
>> documentation should serve as the base knowledge hub.
>>
>
> The javadoc allows users to in a standard way to get documentation
> about the Java DSL they use.
> We already have that.
>
> As an example if you use removeHeaders, then check its javadoc. There
> was a hint about a pattern, so you can remove multiple headers.
>
> What we can do is to take a look on the javadoc, and improve where
> there is gaps. And add links to the EIP page, as well refer to a FAQ
> if there is a common "thing" about this DSL that is good to know (eg
> we refer to the getIn vs getOut FAQ)
>
>>> FAQ-centric documentation is hell for everyone:
>>
>> +1
>>
>
> No FAQ is great. Its common questions.
>
> Again a FAQ should most often not be the single resource of the
> information. But have a description, and point your to links for
> further material, eg where the actual information is.
>
> Of course a FAQ like, can just be without further links
> http://camel.apache.org/can-i-use-camel-on-java-14.html
>
> But a better FAQ has references to other pages
> http://camel.apache.org/how-do-i-debug-my-route.html
FAQs are also great for search engines :)
--
James
-------
Red Hat
Email: jstracha@redhat.com
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/
Open Source Integration
Re: 3.0 Ideas
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Mar 26, 2013 at 5:15 PM, Henryk Konsek <he...@gmail.com> wrote:
>>> Do you guys read the javadoc of the Java DSL? We have java doc on the
>>> DSL where we provide a little information.
>> I know you aren't referring to me, but I'm sure that all dev@ posters have
>> read the Javadocs ;)
>
> We want users to learn about DSL from Javadoc? IMHO reference
> documentation should serve as the base knowledge hub.
>
The javadoc allows users to in a standard way to get documentation
about the Java DSL they use.
We already have that.
As an example if you use removeHeaders, then check its javadoc. There
was a hint about a pattern, so you can remove multiple headers.
What we can do is to take a look on the javadoc, and improve where
there is gaps. And add links to the EIP page, as well refer to a FAQ
if there is a common "thing" about this DSL that is good to know (eg
we refer to the getIn vs getOut FAQ)
>> FAQ-centric documentation is hell for everyone:
>
> +1
>
No FAQ is great. Its common questions.
Again a FAQ should most often not be the single resource of the
information. But have a description, and point your to links for
further material, eg where the actual information is.
Of course a FAQ like, can just be without further links
http://camel.apache.org/can-i-use-camel-on-java-14.html
But a better FAQ has references to other pages
http://camel.apache.org/how-do-i-debug-my-route.html
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: 3.0 Ideas
Posted by Henryk Konsek <he...@gmail.com>.
>> Do you guys read the javadoc of the Java DSL? We have java doc on the
>> DSL where we provide a little information.
> I know you aren't referring to me, but I'm sure that all dev@ posters have
> read the Javadocs ;)
We want users to learn about DSL from Javadoc? IMHO reference
documentation should serve as the base knowledge hub.
> FAQ-centric documentation is hell for everyone:
+1
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: 3.0 Ideas
Posted by Raul Kripalani <ra...@evosent.com>.
Hi Claus,
Responses inline.
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 Mon, Mar 25, 2013 at 4:43 PM, Claus Ibsen <cl...@gmail.com> wrote:
> On Sun, Mar 24, 2013 at 5:23 PM, Henryk Konsek <he...@gmail.com> wrote:
> >> We already have a removeHeaders() DSL [1]
> >
> > Wow, indeed we got it. :)
> >
> > We definitely need to improve our documentation in this regards. I
> > feel pretty familiar with Camel wiki and haven't notice this one :) .
> > I guess that the majority of our users don't know about removeHeaders
> > option as well.
> >
> > I'll try to edit wiki to make this option more visible. Not sure when
> however.
> >
>
> Do you guys read the javadoc of the Java DSL? We have java doc on the
> DSL where we provide a little information.
>
I know you aren't referring to me, but I'm sure that all dev@ posters have
read the Javadocs ;)
> We could enhance this javadoc and add more links to more details at
> the Camel web site. For example in the case of removeHeader DSL we
> could refer to these FAQ's etc.
>
You're just asking for broken links in the Javadocs! We can't guarantee
that a FAQ entry will be alive for the lifetime of a Camel release in the
Maven repos, i.e. forever.
IMHO we should focus on restructuring the website (see below). Let's fix
the base problem instead of patching here and there and creating a jumble
of unmaintainable links throughout time.
Improving docs is always appreciated. For example at any time fell
> free to add FAQ entries for stuff that you feel is good knowledge for
> others.
I beg to differ. FAQ-centric documentation is hell for everyone:
committers, users, evaluators, newbies, etc. Imagine if Wikipedia was a
collection of a bunch of questions like "When was the GMT timezone
created?", "How tall can a Giraffe be?", etc. You get me.
We need better documentation structure. I shared some ideas on overhauling
component pages in May 2012 [1] - before I became a committer. But the need
for a modern website keeps haunting me time after time, as I see other
sites like Apache Cordova [2], Apache Shiro [3], etc. Even the Apache ODE
project [4] – which hasn't seen a release in 2 years – has a refurbished
website!
All in all: new website, new documentation structure.
I guess I'm asking to reignite the discussion here: [5].
[1]
http://camel.465427.n5.nabble.com/Improving-the-Documentation-Articles-Presentations-etc-tp5711559p5713170.html
[2] http://cordova.apache.org/
[3] http://shiro.apache.org/
[4] http://ode.apache.org/
[5] http://camel.apache.org/site-update-ideas.html
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: cibsen@redhat.com
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Re: 3.0 Ideas
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Mar 24, 2013 at 5:23 PM, Henryk Konsek <he...@gmail.com> wrote:
>> We already have a removeHeaders() DSL [1]
>
> Wow, indeed we got it. :)
>
> We definitely need to improve our documentation in this regards. I
> feel pretty familiar with Camel wiki and haven't notice this one :) .
> I guess that the majority of our users don't know about removeHeaders
> option as well.
>
> I'll try to edit wiki to make this option more visible. Not sure when however.
>
Do you guys read the javadoc of the Java DSL? We have java doc on the
DSL where we provide a little information.
We could enhance this javadoc and add more links to more details at
the Camel web site. For example in the case of removeHeader DSL we
could refer to these FAQ's etc.
And we have wanted for years a @Documentation JAXB annotation, so we
could have that as documentation for the XML DSLs. Which we auto
generate the XSD schema from the source code. But sun/oracle haver
never implemented that.
Improving docs is always appreciated. For example at any time fell
free to add FAQ entries for stuff that you feel is good knowledge for
others.
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: 3.0 Ideas
Posted by Henryk Konsek <he...@gmail.com>.
> We already have a removeHeaders() DSL [1]
Wow, indeed we got it. :)
We definitely need to improve our documentation in this regards. I
feel pretty familiar with Camel wiki and haven't notice this one :) .
I guess that the majority of our users don't know about removeHeaders
option as well.
I'll try to edit wiki to make this option more visible. Not sure when however.
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: 3.0 Ideas
Posted by Raul Kripalani <ra...@evosent.com>.
We already have a removeHeaders() DSL [1], but I +1 Matt's idea about
header namespaces and header management altogether.
I find HeaderFilterStrategies essential to avoid leaking implementation
details to external services in the form of transport headers.
Just relying on components to rightfully prefix their metadata with
CamelHttp*, CamelMongo*, etc. will be insufficient if we want to provide
better ways for handling and manipulation.
There has to be a cleverer way, and I think Matt is on the right path here
with his proposal.
Regards,
Raúl.
[1]
http://camel.apache.org/how-to-remove-the-http-protocol-headers-in-the-camel-message.html
Sent while on the move
On 23 Mar 2013 21:32, "Henryk Konsek" <he...@gmail.com> wrote:
> Hi,
>
> > For 3.0.. Have there been any discussions about possible improvement on
> how the
> > headers and properties work across the components?
>
> +1, I like the idea.
>
> I'd like to have possibility to drop/retain headers base on the
> regular expression. For example:
>
> from(...).dropHeaders(regExp("HTTP.*")).to(...);
>
> Maybe we could provide dropHeaders/retainHeaders DSL element taking
> the expression as an argument?
>
> Best regards.
>
> --
> Henryk Konsek
> http://henryk-konsek.blogspot.com
>
Re: 3.0 Ideas
Posted by Henryk Konsek <he...@gmail.com>.
Hi,
> For 3.0.. Have there been any discussions about possible improvement on how the
> headers and properties work across the components?
+1, I like the idea.
I'd like to have possibility to drop/retain headers base on the
regular expression. For example:
from(...).dropHeaders(regExp("HTTP.*")).to(...);
Maybe we could provide dropHeaders/retainHeaders DSL element taking
the expression as an argument?
Best regards.
--
Henryk Konsek
http://henryk-konsek.blogspot.com
Re: 3.0 Ideas
Posted by Matt Pavlovich <ma...@gmail.com>.
For 3.0.. Have there been any discussions about possible improvement on how the headers and properties work across the components?
One of the common headaches is sorting through when component A -> component B, but component A is providing some incompatible headers, or headers that shouldn't be propagated. The solution ends up being clearing a bunch of headers, or resetting some headers using expressions or processors. There is a ton of great value in being able to use the headers to impact component behavior (things like CamelJMSDestinationName, etc), and we definitely don't want to lose that.
It seems to boil down to: How can we strike a balance between the developer (writer of Camel routes) experience and functionality?
I don't have a solution off-hand, but thought it'd make for interesting discussion.
- Maybe its a policy thing? ie.. improved "namespace" of headers? Camel.Jetty.. Camel.CXF.. Camel.HTTP etc..?
- Maybe components leverage Exchange properties more than message headers?
- Maybe there is a special set of properties or headers reserved for Camel components to use, that get dropped by default? getComponentProperties()..
- Maybe a HeaderFilterProcessor that would provide convenience functions for doing common header tasks?
- Maybe just some components need to have a refresh on their header handling?
Things like:
<from uri="jetty:http…"/>
<to uri="jetty:http.."/>
.. and ..
<from uri="cxf:.."/>
<to uri="jetty:.."/>
<from uri="jetty:.."/>
<to uri="cxf:.."/>
<from uri="jetty.."/>
<to uri="cxfrs:.."/>
<from uri="jetty:http.." />
<to uri="http4:// .. "/>
It'd be really handy if the above were interchangeable (aside from payload concerns).
At the same time..
<from uri="jetty.."/>
<to uri="smtp .. "/> (Yikes, need to clear headers!)
<from uri="jetty.."/>
<to uri="jms.. "/> (I want these [x,y,z,a,b,c] headers propagated, but drop the rest.. )
Thanks,
Matt Pavlovich
Re: 3.0 Ideas
Posted by Matt Pavlovich <ma...@gmail.com>.
Hi Dan-
Good call on the JDK's HttpURLConnection as a "stock" http component. If I find some time, I'll take a stab at it.
I have no qualms about leaving the http4 component as the http4, I think the main thing is that the 'http' component (whatever backs it) should be safe for users as a "go to" component out-of-the-box.
Thanks
Matt Pavlovich
On Mar 19, 2013, at 5:11 PM, Daniel Kulp <dk...@apache.org> wrote:
> HttpURLConnection
Re: 3.0 Ideas
Posted by Daniel Kulp <dk...@apache.org>.
On Mar 19, 2013, at 12:32 PM, Matt Pavlovich <ma...@gmail.com> wrote:
> I agree, there are a ton of people using the jms component. My thinking is that if 3.0 is for breakage, than lets get the breakage over with. Line up how we'd like components to look for moving forward, and people migrating could convert to the "legacy" component for compatibility. I think clean component names makes for a better user experience, especially for first-time users.
>
> For example:
> jms -> jms-spring (or other)
> sjms -> jms
> http -> http3
> http4 -> http
>
> The 'http3' and 'jms-spring' components would be an easy change to folks that want to migrate existing routes w/o having to change re-test, and new projects on 3.0 are "clean".
Well, I would like to completely remove the "http3" component. At the very least, make sure it logs some big nasty warnings about it being deprecated and will be removed shortly. There are some nasty security problems in HttpClient 3.x that will not be fixed due to the hc community not supporting it any longer.
I would leave http4 as http4.
Instead, I'd create a light weight "http" based on the HttpURLConnection object in the JDK. Simple, light weight, no extra deps.
Also, I'd like to see http4 updated to use the Async HttpClient. Couple extra deps, but could handle async IO a lot better.
That said, the above is certainly a bit of work. Not sure how much time would need to be involved in it.
Dan
>
> My $0.02.
>
> Thanks,
> Matt Pavlovich
>
> On Mar 18, 2013, at 9:51 PM, Willem jiang <wi...@gmail.com> wrote:
>
>> I'm afraid it is not easy to do that, as there a lots of people using the jms component.
>> It could be same with http component (http client 3.x).
>> BTW, ahc,http and http4 component are using same code in their own module, I think we add the http-common module to let them share the same code.
>>
>>
>> --
>> Willem Jiang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>> Web: http://www.fusesource.com | http://www.redhat.com
>> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
>> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
>> Twitter: willemjiang
>> Weibo: 姜宁willem
>>
>>
>>
>>
>>
>> On Tuesday, March 19, 2013 at 8:38 AM, Matt Pavlovich 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 <sully6768@gmail.com (mailto:sully6768@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 <gnodet@gmail.com (mailto:gnodet@gmail.com)> wrote:
>>>>
>>>>> On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
>>>>> sully6768@gmail.com (mailto: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 (mailto:chris@cxtsoftware.com)>
>>>>>> wrote:
>>>>>>
>>>>>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <gnodet@gmail.com (mailto: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 (mailto:chris@cxtsoftware.com)>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <gnodet@gmail.com (mailto: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 (mailto: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 (mailto:gnodet@redhat.com)
>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Red Hat, Open Source Integration
>>>>>>>>
>>>>>>>> Email: gnodet@redhat.com (mailto: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 (http://sully6768.blogspot.com)
>>>>>> Twitter: sully6768
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Red Hat, Open Source Integration
>>>>>
>>>>> Email: gnodet@redhat.com (mailto: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 (http://sully6768.blogspot.com)
>>>> Twitter: sully6768
>>>
>>
>>
>>
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: 3.0 Ideas
Posted by Matt Pavlovich <ma...@gmail.com>.
I agree, there are a ton of people using the jms component. My thinking is that if 3.0 is for breakage, than lets get the breakage over with. Line up how we'd like components to look for moving forward, and people migrating could convert to the "legacy" component for compatibility. I think clean component names makes for a better user experience, especially for first-time users.
For example:
jms -> jms-spring (or other)
sjms -> jms
http -> http3
http4 -> http
The 'http3' and 'jms-spring' components would be an easy change to folks that want to migrate existing routes w/o having to change re-test, and new projects on 3.0 are "clean".
My $0.02.
Thanks,
Matt Pavlovich
On Mar 18, 2013, at 9:51 PM, Willem jiang <wi...@gmail.com> wrote:
> I'm afraid it is not easy to do that, as there a lots of people using the jms component.
> It could be same with http component (http client 3.x).
> BTW, ahc,http and http4 component are using same code in their own module, I think we add the http-common module to let them share the same code.
>
>
> --
> Willem Jiang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Web: http://www.fusesource.com | http://www.redhat.com
> Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
> http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
> Twitter: willemjiang
> Weibo: 姜宁willem
>
>
>
>
>
> On Tuesday, March 19, 2013 at 8:38 AM, Matt Pavlovich 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 <sully6768@gmail.com (mailto:sully6768@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 <gnodet@gmail.com (mailto:gnodet@gmail.com)> wrote:
>>>
>>>> On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
>>>> sully6768@gmail.com (mailto: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 (mailto:chris@cxtsoftware.com)>
>>>>> wrote:
>>>>>
>>>>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <gnodet@gmail.com (mailto: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 (mailto:chris@cxtsoftware.com)>
>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <gnodet@gmail.com (mailto: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 (mailto: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 (mailto:gnodet@redhat.com)
>>>>>>>>> Web: http://fusesource.com
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Red Hat, Open Source Integration
>>>>>>>
>>>>>>> Email: gnodet@redhat.com (mailto: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 (http://sully6768.blogspot.com)
>>>>> Twitter: sully6768
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> ------------------------
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Red Hat, Open Source Integration
>>>>
>>>> Email: gnodet@redhat.com (mailto: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 (http://sully6768.blogspot.com)
>>> Twitter: sully6768
>>
>
>
>
Re: 3.0 Ideas
Posted by Willem jiang <wi...@gmail.com>.
I'm afraid it is not easy to do that, as there a lots of people using the jms component.
It could be same with http component (http client 3.x).
BTW, ahc,http and http4 component are using same code in their own module, I think we add the http-common module to let them share the same code.
--
Willem Jiang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang
Weibo: 姜宁willem
On Tuesday, March 19, 2013 at 8:38 AM, Matt Pavlovich 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 <sully6768@gmail.com (mailto:sully6768@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 <gnodet@gmail.com (mailto:gnodet@gmail.com)> wrote:
> >
> > > On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
> > > sully6768@gmail.com (mailto: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 (mailto:chris@cxtsoftware.com)>
> > > > wrote:
> > > >
> > > > > On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <gnodet@gmail.com (mailto: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 (mailto:chris@cxtsoftware.com)>
> > > > > wrote:
> > > > > >
> > > > > > > On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <gnodet@gmail.com (mailto: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 (mailto: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 (mailto:gnodet@redhat.com)
> > > > > > > > Web: http://fusesource.com
> > > > > > > > Blog: http://gnodet.blogspot.com/
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > > > ------------------------
> > > > > > Red Hat, Open Source Integration
> > > > > >
> > > > > > Email: gnodet@redhat.com (mailto: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 (http://sully6768.blogspot.com)
> > > > Twitter: sully6768
> > >
> > >
> > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > > ------------------------
> > > Red Hat, Open Source Integration
> > >
> > > Email: gnodet@redhat.com (mailto: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 (http://sully6768.blogspot.com)
> > Twitter: sully6768
>
Re: 3.0 Ideas
Posted by Matt Pavlovich <ma...@gmail.com>.
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 <su...@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 <gn...@gmail.com> wrote:
>
>> 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 <ch...@cxtsoftware.com>
>>> wrote:
>>>
>>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <gn...@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 <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/
>>
>
>
>
> --
> --
> 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