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