On 7/29/13 11:11 AM, Mark Thomas wrote: > On 29/07/2013 19:56, Phil Steitz wrote: >> On 7/24/13 1:06 PM, Mark Thomas wrote: >>> On 24/07/2013 21:01, ma...@apache.org wrote: >>>> Author: markt >>>> Date: Wed Jul 24 20:01:34 2013 >>>> New Revision: 1506685 >>>> >>>> URL: http://svn.apache.org/r1506685 >>>> Log: >>>> Create two new factory interfaces that work with PooledObject instances >>>> rather than Object instances and switch Gop and GKOP to use them. >>> One area I'd particularly like some comment on is PooledObject & >>> PooledObjectImpl. >>> >>> I considered just having a single PooledObject implementation class in >>> o.a.c.pool2 but decided that as implementation it belonged in >>> o.a.c.pool2.impl. That lead to needing PoolImplUtils. >>> >>> I'm not completely happy with the current arrangement but neither have a >>> found a better one. Thoughts? >> I wonder if we really want / need to retain the original "dumb" (not >> in the sense of bad design, but no tracking) pooling infrastructure >> from 1.x. Thinking about making it easy for users to grokk the >> setup and get a GOP or GKOP working, I wonder if it might be better >> to drop the base classes and just start with simple, refactored pool >> and factory interfaces that create and manage PooledObjects >> directly. Users will still only absolutely *have* to implement >> makeObject in their factories and the default code will take care of >> everything else. So you just end up with PoolableObjectFactories >> sourcing and managing PooledObjects. GOP, GKOP still return >> unwrapped objects via borrow and there is an >> AbstractPoolableObjectFactory with makeObject abstract and the rest >> provided. I have not played with this yet (hopefully will have some >> time in the next couple of days), but I wonder if it might not be >> better / simpler. Also, adding methods to GOP, GKOP that return >> PooledObject instances (maybe stripped down) might be useful to >> clients. Sorry if above is naive / old ground. I just want to make >> sure what we end up with is a simple as possible. > That is certainly do-able. The question is what does it mean for the > various implementations like SoftReferenceObjectPool and those provided > by PoolUtils. > > If there are implementations there are are no longer required or > rendered obsolete by the Pool2 impl then a big +1 from me to removing them.
No reason the ones we keep could not be modified to use the new setup. I have not taken a close look at all of the aminals in the PoolUtils zoo recently, but I bet a lot of them are obsolete in the 2.0 world. Phil > > Mark > > > --------------------------------------------------------------------- > 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
