I have started working on this. Should have something to commit at least for GOP in the next day or two.
Phil On 7/29/13 10:56 AM, 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. > > 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
