Quantcast

3.0 Ideas

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

3.0 Ideas

Chris Geer
I'd like to cast my vote for a couple things we'd like to see in Camel 3.0
if it can be fit in.

1) Refactor the JMS Component to use JTA transactions instead of Spring
Transactions.
2) We agree with the existing idea for "JMX Naming" on the idea page.
Removing the hostname from the JMX names would be a great improvement.

I'll be glad to help where I can on these items if the community agrees
they are good for the product. I don't have write access to the ideas page
so I can't add the JMS Component one myself.

Chris
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

hekonsek
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? :)

Best regards.

--
Henryk Konsek
http://henryk-konsek.blogspot.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Chris Geer
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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Chris Geer
CAMEL-6108 <https://issues.apache.org/jira/browse/CAMEL-6108>

On Wed, Feb 27, 2013 at 1:50 PM, Chris Geer <[hidden email]> 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
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Guillaume Nodet
Administrator
In reply to this post by Chris Geer
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.


On Wed, Feb 27, 2013 at 9:50 PM, Chris Geer <[hidden email]> 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: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Chris Geer
On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]> 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 <[hidden email]> 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: [hidden email]
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Claus Ibsen-2
On Thu, Feb 28, 2013 at 1:22 AM, Chris Geer <[hidden email]> wrote:

> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]> 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.
>

You should use camel-sjms instead, its the JMS component without
spring dependencies.
You can use JTA transactions with that.


>>
>>
>> On Wed, Feb 27, 2013 at 9:50 PM, Chris Geer <[hidden email]> 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: [hidden email]
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/
>>



--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Guillaume Nodet
Administrator
In reply to this post by Chris Geer
if you configure spring to use the JtaTransactionManager which inherits
from PlatformTransactionManager, then you'll have the spring transaction
layer using JTA.



On Thu, Feb 28, 2013 at 1:22 AM, Chris Geer <[hidden email]> wrote:

> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]> 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 <[hidden email]>
> 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: [hidden email]
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>



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

Email: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Chris Geer
In reply to this post by Claus Ibsen-2
On Wed, Feb 27, 2013 at 10:20 PM, Claus Ibsen <[hidden email]> wrote:

> On Thu, Feb 28, 2013 at 1:22 AM, Chris Geer <[hidden email]> wrote:
> > On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]>
> 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.
> >
>
> You should use camel-sjms instead, its the JMS component without
> spring dependencies.
> You can use JTA transactions with that.
>

Claus,

For the moment we are still on Camel 2.10.x so SJMS isn't quite an option.
We are also making use of XA transactions (we use the activemq components
which extends from JMS component) at the moment so it doesn't look like
SJMS is going to fit. I'll keep it in mind as we progress into Camel 2.11+.

The ActiveMQ component with the Spring PlatformTransactionManager is
working right now so we don't have to switch today.

Thanks,
Chris

>
>
> >>
> >>
> >> On Wed, Feb 27, 2013 at 9:50 PM, Chris Geer <[hidden email]>
> 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: [hidden email]
> >> Web: http://fusesource.com
> >> Blog: http://gnodet.blogspot.com/
> >>
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> FuseSource is now part of Red Hat
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Chris Geer
In reply to this post by Guillaume Nodet
On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email]> 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 <[hidden email]> wrote:
>
> > On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]>
> 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 <[hidden email]>
> > 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: [hidden email]
> > > Web: http://fusesource.com
> > > Blog: http://gnodet.blogspot.com/
> > >
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: [hidden email]
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

sully6768
+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.


On Thu, Feb 28, 2013 at 11:30 AM, Chris Geer <[hidden email]> wrote:

> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email]>
> 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 <[hidden email]>
> wrote:
> >
> > > On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]>
> > 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 <[hidden email]>
> > > 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: [hidden email]
> > > > Web: http://fusesource.com
> > > > Blog: http://gnodet.blogspot.com/
> > > >
> > >
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Red Hat, Open Source Integration
> >
> > Email: [hidden email]
> > 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
--
Scott England-Sullivan
----------------------------------
FuseSource
Web:     http://www.fusesource.com
Blog:     http://sully6768.blogspot.com
Twitter: sully6768
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Guillaume Nodet
Administrator
On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <[hidden email]
> 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 <[hidden email]>
> wrote:
>
> > On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email]>
> > 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 <[hidden email]>
> > wrote:
> > >
> > > > On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]>
> > > 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 <[hidden email]
> >
> > > > 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: [hidden email]
> > > > > Web: http://fusesource.com
> > > > > Blog: http://gnodet.blogspot.com/
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > ------------------------
> > > Guillaume Nodet
> > > ------------------------
> > > Red Hat, Open Source Integration
> > >
> > > Email: [hidden email]
> > > 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: [hidden email]
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

sully6768
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 <[hidden email]> wrote:

> On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
> [hidden email]
> > 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 <[hidden email]>
> > wrote:
> >
> > > On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email]>
> > > 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 <[hidden email]>
> > > wrote:
> > > >
> > > > > On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]
> >
> > > > 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 <
> [hidden email]
> > >
> > > > > 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: [hidden email]
> > > > > > Web: http://fusesource.com
> > > > > > Blog: http://gnodet.blogspot.com/
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > ------------------------
> > > > Guillaume Nodet
> > > > ------------------------
> > > > Red Hat, Open Source Integration
> > > >
> > > > Email: [hidden email]
> > > > 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: [hidden email]
> 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
--
Scott England-Sullivan
----------------------------------
FuseSource
Web:     http://www.fusesource.com
Blog:     http://sully6768.blogspot.com
Twitter: sully6768
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Matt Pavlovich
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 <[hidden email]> 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 <[hidden email]> wrote:
>
>> On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
>> [hidden email]
>>> 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 <[hidden email]>
>>> wrote:
>>>
>>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email]>
>>>> 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 <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]
>>>
>>>>> 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 <
>> [hidden email]
>>>>
>>>>>> 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: [hidden email]
>>>>>>> Web: http://fusesource.com
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ------------------------
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Red Hat, Open Source Integration
>>>>>
>>>>> Email: [hidden email]
>>>>> 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: [hidden email]
>> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Raul Kripalani
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" <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]>
> wrote:
> >
> >> On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
> >> [hidden email]
> >>> 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 <[hidden email]>
> >>> wrote:
> >>>
> >>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email]>
> >>>> 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 <[hidden email]>
> >>>> wrote:
> >>>>>
> >>>>>> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]
> >>>
> >>>>> 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 <
> >> [hidden email]
> >>>>
> >>>>>> 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: [hidden email]
> >>>>>>> Web: http://fusesource.com
> >>>>>>> Blog: http://gnodet.blogspot.com/
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> ------------------------
> >>>>> Guillaume Nodet
> >>>>> ------------------------
> >>>>> Red Hat, Open Source Integration
> >>>>>
> >>>>> Email: [hidden email]
> >>>>> 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: [hidden email]
> >> 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
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Willem.Jiang
In reply to this post by Matt Pavlovich
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 <[hidden email] (mailto:[hidden email])> 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 <[hidden email] (mailto:[hidden email])> wrote:
> >  
> > > On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
> > > [hidden email] (mailto:[hidden email])
> > > > 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 <[hidden email] (mailto:[hidden email])>
> > > > wrote:
> > > >  
> > > > > On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email] (mailto:[hidden email])>
> > > > > 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 <[hidden email] (mailto:[hidden email])>
> > > > > wrote:
> > > > > >  
> > > > > > > On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email] (mailto:[hidden email])
> > > >  
> > > > > > 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 <
> > > [hidden email] (mailto:[hidden email])
> > > > >  
> > > > > > > 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: [hidden email] (mailto:[hidden email])
> > > > > > > > Web: http://fusesource.com
> > > > > > > > Blog: http://gnodet.blogspot.com/
> > > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > >  
> > > > > > --
> > > > > > ------------------------
> > > > > > Guillaume Nodet
> > > > > > ------------------------
> > > > > > Red Hat, Open Source Integration
> > > > > >  
> > > > > > Email: [hidden email] (mailto:[hidden email])
> > > > > > 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: [hidden email] (mailto:[hidden email])
> > > 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
>  



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Matt Pavlovich
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 <[hidden email]> 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 <[hidden email] (mailto:[hidden email])> 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 <[hidden email] (mailto:[hidden email])> wrote:
>>>
>>>> On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
>>>> [hidden email] (mailto:[hidden email])
>>>>> 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 <[hidden email] (mailto:[hidden email])>
>>>>> wrote:
>>>>>
>>>>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email] (mailto:[hidden email])>
>>>>>> 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 <[hidden email] (mailto:[hidden email])>
>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email] (mailto:[hidden email])
>>>>>
>>>>>>> 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 <
>>>> [hidden email] (mailto:[hidden email])
>>>>>>
>>>>>>>> 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: [hidden email] (mailto:[hidden email])
>>>>>>>>> Web: http://fusesource.com
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Red Hat, Open Source Integration
>>>>>>>
>>>>>>> Email: [hidden email] (mailto:[hidden email])
>>>>>>> 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: [hidden email] (mailto:[hidden email])
>>>> 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
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Matt Pavlovich
In reply to this post by Raul Kripalani
Thanks Raul.  Added myself as a watcher and I'm available for testing help.

On Mar 18, 2013, at 8:57 PM, Raul Kripalani <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]>
>> wrote:
>>>
>>>> On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
>>>> [hidden email]
>>>>> 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 <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email]>
>>>>>> 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 <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email]
>>>>>
>>>>>>> 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 <
>>>> [hidden email]
>>>>>>
>>>>>>>> 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: [hidden email]
>>>>>>>>> Web: http://fusesource.com
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Red Hat, Open Source Integration
>>>>>>>
>>>>>>> Email: [hidden email]
>>>>>>> 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: [hidden email]
>>>> 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
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

Raul Kripalani
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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]
> >
> >> 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 <[hidden email]>
> >> wrote:
> >>>
> >>>> On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
> >>>> [hidden email]
> >>>>> 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 <[hidden email]>
> >>>>> wrote:
> >>>>>
> >>>>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email]
> >
> >>>>>> 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 <[hidden email]
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <
> [hidden email]
> >>>>>
> >>>>>>> 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 <
> >>>> [hidden email]
> >>>>>>
> >>>>>>>> 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: [hidden email]
> >>>>>>>>> Web: http://fusesource.com
> >>>>>>>>> Blog: http://gnodet.blogspot.com/
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> ------------------------
> >>>>>>> Guillaume Nodet
> >>>>>>> ------------------------
> >>>>>>> Red Hat, Open Source Integration
> >>>>>>>
> >>>>>>> Email: [hidden email]
> >>>>>>> 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: [hidden email]
> >>>> 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
> >>
> >>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 3.0 Ideas

dkulp@apache.org
In reply to this post by Matt Pavlovich

On Mar 19, 2013, at 12:32 PM, Matt Pavlovich <[hidden email]> 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 <[hidden email]> 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 <[hidden email] (mailto:[hidden email])> 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 <[hidden email] (mailto:[hidden email])> wrote:
>>>>
>>>>> On Thu, Feb 28, 2013 at 6:55 PM, Scott England-Sullivan <
>>>>> [hidden email] (mailto:[hidden email])
>>>>>> 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 <[hidden email] (mailto:[hidden email])>
>>>>>> wrote:
>>>>>>
>>>>>>> On Thu, Feb 28, 2013 at 12:14 AM, Guillaume Nodet <[hidden email] (mailto:[hidden email])>
>>>>>>> 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 <[hidden email] (mailto:[hidden email])>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Wed, Feb 27, 2013 at 5:16 PM, Guillaume Nodet <[hidden email] (mailto:[hidden email])
>>>>>>
>>>>>>>> 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 <
>>>>> [hidden email] (mailto:[hidden email])
>>>>>>>
>>>>>>>>> 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: [hidden email] (mailto:[hidden email])
>>>>>>>>>> Web: http://fusesource.com
>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> ------------------------
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Red Hat, Open Source Integration
>>>>>>>>
>>>>>>>> Email: [hidden email] (mailto:[hidden email])
>>>>>>>> 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: [hidden email] (mailto:[hidden email])
>>>>> 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
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

12
Loading...