camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Edstrom <seij...@gmail.com>
Subject Re: [CAMEL-5416] Camel Simple JMS Component
Date Mon, 09 Jul 2012 21:21:23 GMT
Is there any reason for not using commons pool then?
Just a stupid question.


On Jul 9, 2012, at 21:53, Scott England-Sullivan <sully6768@gmail.com> wrote:

> Christian,
> 
> I am looking into creating a new Apache Commons project for the messaging.
> As information becomes available I will let you know.
> 
> On Thu, Jul 5, 2012 at 6:29 PM, Scott England-Sullivan
> <sully6768@gmail.com>wrote:
> 
>> Hi Christian,
>> 
>> I noticed after the fact that this was stated as a goal in the Camel
>> roadmap.  The thought was to develop the JMS API so it could be pulled out
>> to use as a commons project for reuse in CXF.  For the moment the
>> implementation design consists of internal classes that allow the Camel
>> consumers and producers to manage pools of JMS consumers and producers that
>> take advantage of inline resource  resolution.  This allows for a very
>> small coding foot print that is easy to manage and evolve.
>> 
>> In general it would just be a matter of pulling those internal class
>> definitions out and building up the constructors.  I will have to take a
>> look and see what it would take but it will be several weeks.  Duty calls
>> and I have several engagements coming up that have me on the road.
>> 
>> I will keep you posted though.
>> 
>> 
>> On Wed, Jul 4, 2012 at 10:00 AM, Christian Schneider <
>> chris@die-schneider.net> wrote:
>> 
>>> I wonder if it would make sense to check what parts of this impl could be
>>> resused in cxf for the jms transport.
>>> There we also would like to have a jms transport without spring and a lot
>>> of the code should be pretty similar.
>>> 
>>> Christian
>>> 
>>> Am 03.07.2012 22:26, schrieb Scott England-Sullivan:
>>> 
>>> Hi All,
>>>> 
>>>> I have an alpha release of a pure Java JMS Camel Component (no Spring
>>>> dependencies).  I created CAMEL-5416 to for tracking of the component.
>>>> The
>>>> initial goals are:
>>>> 
>>>> First Iteration:
>>>> Full Queue and Topic Support (Durable & Non-Durable)
>>>> Full InOnly & InOut Support
>>>> Internal Connection, Session, Consumer, & Producer pooling/caching
>>>> management
>>>> Full Asynchronous Support
>>>> JMS Internal Transaction Support
>>>> 
>>>> Future Iterations:
>>>> Camel Transaction Support
>>>> JTA Support (Pure Java)
>>>> Robust-InOnly
>>>> Full Migration of Core Camel-JMS Unit Tests (where applicable)
>>>> 
>>>> The source can be found here: https://github.com/sully6768/**
>>>> camel-sandbox <https://github.com/sully6768/camel-sandbox>.
>>>> 
>>>> Before releasing it to the Camel Project, I would appreciate feedback
>>>> from
>>>> the community so please feel free to come in and kick the tires.  It is
>>>> an
>>>> alpha though but getting very close to what could be considered a beta.
>>>> 
>>>> I will provide an update to the ReadMe in the next couple of days that
>>>> will
>>>> cover the basics.
>>>> 
>>>> If you have any initial comments, please feel free to chime in.
>>>> 
>>>> Best Regards,
>>>> Scott ES
>>>> 
>>>> 
>>> 
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>> 
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>> 
>>> 
>> 
>> 
>> --
>> --
>> Scott England-Sullivan
>> ----------------------------------
>> FuseSource
>> Web:     http://www.fusesource.com
>> Blog:     http://sully6768.blogspot.com
>> Twitter: sully6768
>> 
>> 
> 
> 
> -- 
> -- 
> Scott England-Sullivan
> ----------------------------------
> FuseSource
> Web:     http://www.fusesource.com
> Blog:     http://sully6768.blogspot.com
> Twitter: sully6768

Mime
View raw message