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 <seij...@gmail.com> 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 <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 > -- -- Scott England-Sullivan ---------------------------------- FuseSource Web: http://www.fusesource.com Blog: http://sully6768.blogspot.com Twitter: sully6768
