I apologize for not getting the proposal for the MBean API out quite yet - needed some sleep last night =)
Gary, it seems your question is more approaching the issue academically, asking if the configuration can be extracted (indeed, abstracted) for reuse. Depending on your intent, this may or may not having anything to do with the JMX proposal....especially if this would inherently be abstracted out as well. I'm going to be playing with the code this evening (hopefully), so I'll have a better footing to comment on this issue...but seems pretty logical to me. Steve On Wed, Oct 20, 2010 at 3:13 PM, 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://people.apache.org/%7Esimonetripodi/> > 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 > >
