commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [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 18:29:14 GMT
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, 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.
> 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.

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

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

View raw message