camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: 3.0 Ideas
Date Tue, 19 Mar 2013 21:11:51 GMT

On Mar 19, 2013, at 12:32 PM, Matt Pavlovich <mattrpav@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 <willem.jiang@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


Mime
View raw message