sure, I always wait for feedbacks before coding :P Cool expression "Rambo through the code", that was the first time I read it and made me laugh :D All the best, Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Oct 20, 2010 at 9:17 PM, Gary Gregory <ggreg...@seagullsoftware.com> wrote: > It seems to me there is a reason the code is the way it is so I'd really like > to hear thoughts from some of the original authors before we go and Rambo > through the code ;) > > Gary > > On Oct 20, 2010, at 12:13, "Simone Tripodi" <simone.trip...@gmail.com> wrote: > >> Hi Gary, >> yes that's me that raised the question[1] and discussed a little with >> Seb. What blocked me was the JMX support proposal since I'm not >> familiar with that technology, so I was consulting documentation to >> study. >> >> My very big +1 for that, with the wish of work directly on that stuff. >> Anyone else has a different thought, before proceeding? >> Thanks in advance, >> Simo >> >> [1] http://markmail.org/message/q4y7ghux57s7hk6v >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Wed, Oct 20, 2010 at 7:43 PM, Gary Gregory >> <ggreg...@seagullsoftware.com> wrote: >>> In the same department, I see the following ivars: >>> >>> lifo : boolean >>> maxActive : int >>> maxIdle : int >>> maxTotal : int >>> maxWait : long >>> minEvictableIdleTimeMillis : long >>> minIdle : int >>> numTestsPerEvictionRun : int >>> testOnBorrow : boolean >>> testOnReturn : boolean >>> testWhileIdle : boolean >>> timeBetweenEvictionRunsMillis : long >>> whenExhaustedAction : WhenExhaustedAction >>> >>> defined in four classes: >>> >>> GenericKeyedObjectPool >>> GenericKeyedObjectPoolFactory >>> GenericObjectPool >>> GenericObjectPoolFactory >>> >>> Which feels to me like a missed opportunity to avoid duplication. >>> >>> Is making one ivar private or final or volatile be applied to all four >>> classes? >>> >>> We could: >>> >>> Use a config object instead of the 13 ivars. >>> Or a common superclass then we can consider if it should hold the ivar list >>> or a Config object. >>> >>> Would it be too weird to have a common super class for BaseObjectPool and >>> BasePoolableObjectFactory for example? >>> >>> 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 >>> >>> >>> >>>> -----Original Message----- >>>> From: Gary Gregory [mailto:ggreg...@seagullsoftware.com] >>>> Sent: Wednesday, October 20, 2010 10:29 >>>> To: Commons Developers List >>>> Subject: [pool] Reusing Config >>>> >>>> Hi All: >>>> >>>> I think this came up recently. Any thoughts or plans on extracting the >>>> Config >>>> class out of GenericKeyedObjectPool and GenericObjectPool so it can be >>>> reused. >>>> The constants for default values could then also be moved to Config. >>>> 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<mailto:ggreg...@seagullsoftware.com> >>>> Web: seagull.rocketsoftware.com<http://www.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