Hi Gary, I have the same trouble, and that's why I wrote my previous email; in the Stack(Keyed)ObjectPool(Factory) I implemented the Config class as immutable, as discussed in a previous thread in the ML, so I had to copy the data from the config to pool/factory to allow the mutability. I fond it a little redundant and not easy to keep in sync in the case of Generic(Keyed)ObjectPool(Factory), I already gave a try to refactor the Generic* classes but I failed so I had to revert my local changes. I find the current Generic* approach much more agile and adaptable.
So now we can compare on /trunk both approaches and I honestly think we have to make a final decision on wich of the two fits better to our needs; I'm open like always to suggestions, but we should find a unique way to manage the configuration stuff. Have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Fri, Oct 29, 2010 at 4:58 PM, Gary Gregory <ggreg...@seagullsoftware.com> wrote: >> -----Original Message----- >> From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On >> Behalf Of James Carman >> Sent: Friday, October 29, 2010 20:46 >> To: Commons Developers List >> Subject: Re: [pool] Pool config vs. factory hierarchies. >> >> If the config objects are immutable, then you can store the reference. > > I thought we said that pools settings should be configurable. The current > Config root class has setters. > > Are we saying that, yes, pools are configurable post-creation but not through > config objects? Should config objects be cloned when passed in a constructor > then? > > Gary > >> >> On Fri, Oct 29, 2010 at 10:34 AM, Simone Tripodi >> <simone.trip...@gmail.com> wrote: >> > Hi again Gary, >> > the only thing I'm not sure about the patch - not blockin anyway, it >> > can be modified later - is that one of the discussed requirement was >> > not storing the config reference but rather copying the data. >> > BTW I like the design!!! >> > Simo >> > >> > http://people.apache.org/~simonetripodi/ >> > http://www.99soft.org/ >> > >> > >> > >> > On Fri, Oct 29, 2010 at 4:28 PM, Simone Tripodi >> > <simone.trip...@gmail.com> wrote: >> >> Hi Gary, >> >> well done, it seems to me it is a very good work, +1 on applying this >> patch!!! >> >> Have a nice day, >> >> Simo >> >> >> >> http://people.apache.org/~simonetripodi/ >> >> http://www.99soft.org/ >> >> >> >> >> >> >> >> On Fri, Oct 29, 2010 at 3:55 PM, Gary Gregory >> >> <ggreg...@seagullsoftware.com> wrote: >> >>> Hi All, >> >>> >> >>> I see now in trunk that GenericKeyedObjectPoolConfig extends >> GenericObjectPoolConfig, which I like. >> >>> >> >>> It seems that the next step would be for GenericKeyedObjectPoolFactory >> >>> and >> GenericObjectPoolFactory to share a common superclass. >> >>> >> >>> To see what I mean, look at the patch in >> https://issues.apache.org/jira/browse/POOL-177. >> >>> >> >>> Beyond that, the idea would be to pull up the factory ivar. >> >>> >> >>> Gary Gregory >> >>> Senior Software Engineer >> >>> Rocket Software >> >>> 3340 Peachtree Road, Suite 820 . Atlanta, GA 30326 . USA >> >>> Tel: +1.404.760.1560 >> >>> Email: ggreg...@seagullsoftware.com >> >>> Web: seagull.rocketsoftware.com >> >>> >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >>> >> >>> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
