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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
