[CAMEL-5416] Camel Simple JMS Component

[sully6768]

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.

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

--
Scott England-Sullivan
----------------------------------
FuseSource
Web:     http://www.fusesource.com
Blog:     http://sully6768.blogspot.com
Twitter: sully6768

[aedwards]

wondering if you have considered allowing it to take a java "List", and then sending all the separate elements to the JMS provider as separate Messages within the same transaction?   I wrote a small bean which does this for performance reasons(since batching the transaction creates a noticeable performance gain), it would be nice to add this functionality within your new component.

[sully6768]

Excellent suggestion.  I will add it to the list of to-do's.  Thanks for
the feedback.

On Wed, Jul 4, 2012 at 9:30 AM, aedwards <[hidden email]> wrote:

> wondering if you have considered allowing it to take a java "List", and
> then
> sending all the separate elements to the JMS provider as separate Messages
> within the same transaction?   I wrote a small bean which does this for
> performance reasons(since batching the transaction creates a noticeable
> performance gain), it would be nice to add this functionality within your
> new component.
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/CAMEL-5416-Camel-Simple-JMS-Component-tp5715423p5715490.html
> Sent from the Camel Development mailing list archive at Nabble.com.
>

--
--
Scott England-Sullivan
----------------------------------
FuseSource
Web:     http://www.fusesource.com
Blog:     http://sully6768.blogspot.com
Twitter: sully6768

[Christian Schneider]

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

[sully6768]

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

[sully6768]

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

[Johan Edstrom-2]

Is there any reason for not using commons pool then?
Just a stupid question.


On Jul 9, 2012, at 21:53, Scott England-Sullivan <[hidden email]> 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
> <[hidden email]>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 <
>> [hidden email]> 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

[Johan Edstrom-2]

Also, are we paying attention to pool reusage in a container?

Another dumb question ;)

On Jul 9, 2012, at 21:53, Scott England-Sullivan <[hidden email]> 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
> <[hidden email]>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 <
>> [hidden email]> 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

[sully6768]

Hi Johan,

For me It comes down to the same reason as "why not Spring"; reduce
external dependencies and influences, increased resiliency & simplified
maintenance.  Aside from creating a Camel JMS component free from the
Spring messaging APIs and its known limitations, one of my principal goals
in this effort was to increase resiliency by limiting dependencies and
lines of code (LOC).  I felt the commons-pool API fell into this
same category.  I have run into resiliency issues with commons-pool project
in the past and in reviewing it for inclusion in this project felt it was
to geared for the general audience making it susceptible to resiliency
issues.

I could be way out on this and am more than happy to adopt it for the base
pooling API but would need the input of others before I would go there.
 (Sorry for the long backstory but I felt it added context.)

On Mon, Jul 9, 2012 at 3:21 PM, Johan Edstrom <[hidden email]> wrote:

> Is there any reason for not using commons pool then?
> Just a stupid question.
>
>
> On Jul 9, 2012, at 21:53, Scott England-Sullivan <[hidden email]>
> 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
> > <[hidden email]>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 <
> >> [hidden email]> 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
>

--
--
Scott England-Sullivan
----------------------------------
FuseSource
Web:     http://www.fusesource.com
Blog:     http://sully6768.blogspot.com
Twitter: sully6768

[sully6768]

Hi again Johan,

If you are referring to the nested classes, yes, as the patterns of
reusability have appeared I have refactoring the code base.  My initial
efforts started with trying to develop the pooling logic in a more generic
manner external to the producer and consumer classes but all the possible
permutations became overwhelming.  I found that using nested pool objects
allowed them to evolve more cleanly when developed for a single purpose.
 As such, some of the pools have begun to boil down into more common and
stable patterns that may be candidates for refactoring out for reuse.  The
non-transacted MessageQueue listener pool is an example as it is used by
both the InOnlyConsumer and the InOutProducer.

My thought was (and I could be way over thinking this) at that point that
if the pools are predominately single use then does it make sense to
refactor them out and now require large constructors and/or setters with
error logic that are already accounted for in the parent of the nested
pool?  More LOC reduces resiliency and that isn't something I really want
to sacrifice.

Thoughts?

PS: Regarding "dumb questions".  Quite frankly, exposing ones efforts to
this community, especially one with the visibility of the JMS component, is
intimidating and I keep waiting for the "why did you do that you idiot"
comment. ;)


On Mon, Jul 9, 2012 at 3:25 PM, Johan Edstrom <[hidden email]> wrote:

> Also, are we paying attention to pool reusage in a container?

> Another dumb question ;)
>
> On Jul 9, 2012, at 21:53, Scott England-Sullivan <[hidden email]>
> 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
> > <[hidden email]>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 <
> >> [hidden email]> 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
>

--
--
Scott England-Sullivan
----------------------------------
FuseSource
Web:     http://www.fusesource.com
Blog:     http://sully6768.blogspot.com
Twitter: sully6768