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 <seij...@gmail.com> 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 <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
