commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject [pool] 2.0 factory interfaces WAS: Re: svn commit: r1506685 - in /commons/proper/pool/trunk/src: main/java/org/apache/commons/pool2/ main/java/org/apache/commons/pool2/impl/ test/java/org/apache/commons/pool2/ test/java/org/apache/commons/pool2/impl/ test/java/org/apache/commons/pool2/perfo...
Date Mon, 29 Jul 2013 17:56:46 GMT
On 7/24/13 1:06 PM, Mark Thomas wrote:
> On 24/07/2013 21:01, wrote:
>> Author: markt
>> Date: Wed Jul 24 20:01:34 2013
>> New Revision: 1506685
>> URL:
>> 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.

> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message