You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2013/07/29 19:56:46 UTC
[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...
On 7/24/13 1:06 PM, Mark Thomas wrote:
> On 24/07/2013 21:01, markt@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
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...
Posted by Phil Steitz <ph...@gmail.com>.
On 8/4/13 9:27 AM, Phil Steitz wrote:
> On 8/4/13 7:24 AM, Mark Thomas wrote:
>> On 03/08/2013 17:15, Phil Steitz wrote:
>>> On 7/30/13 9:16 AM, Phil Steitz wrote:
>>>> I have started working on this. Should have something to commit at
>>>> least for GOP in the next day or two.
>>> I am stuck on SoftReferenceObectPool.
>> :(
>>
>>> I have been able to handle
>>> everything else collapsing down to just Pooled(Keyed)ObjectFactory /
>>> Base(Keyed)ObjectPool.
>> Excellent.
>>
>>> To stick with (and get factory / monitoring
>>> benefits of) PooledObjectFactory / PooledObjects, I need to create a
>>> version of DefaultPooledObject that wraps SoftReferences and these
>>> have to be mutable - i.e., when an instance is returned a new soft
>>> reference is created and stored in the pool, but we want to maintain
>>> PooledObject state. To do this, I need to be able to recognize the
>>> returning object. I could do this by searching the pool, but that
>>> will cost something. On the other hand, the lack of search now
>>> means returnObject is not idempotent (like it is in the rest of the
>>> 2.0 pools). Multiple returns will put multiple soft references to
>>> the same object in the pool.
>>>
>>> So, I would appreciate some feedback on the following options:
>>>
>>> 1) Add a search for the returning object and create a
>>> PooledSoftReference subclass of DefaultPooledObject within
>>> SoftReferencePool to be stored in the pool.
>>>
>>> 2) Keep PoolableObjectFactory just for this pool and leave it alone,
>>> adding a warning to returnObject (not a new issue, just different
>>> from other 2.0 pools).
>> I think the benefits of the monitoring justify adding the search so my
>> preference is for option 1.
> Drat, I thought I was going to get away with 2) - he he. I will
> plow ahead with 1 :)
OK, done now. All tests pass. I am just cleaning up javadoc and
will commit in next 24 hours. I have not added JMX stuff to
SoftReferenceObjectPool, but will do that after committing the
initial refactoring. I also did not clean up the complete sync and
spurious notifies in SoftReferenceObjectPool. That can also be
looked at next. More observations on this class to follow post-commit.
Phil
>
> Phil
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
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...
Posted by Phil Steitz <ph...@gmail.com>.
On 8/4/13 7:24 AM, Mark Thomas wrote:
> On 03/08/2013 17:15, Phil Steitz wrote:
>> On 7/30/13 9:16 AM, Phil Steitz wrote:
>>> I have started working on this. Should have something to commit at
>>> least for GOP in the next day or two.
>> I am stuck on SoftReferenceObectPool.
> :(
>
>> I have been able to handle
>> everything else collapsing down to just Pooled(Keyed)ObjectFactory /
>> Base(Keyed)ObjectPool.
> Excellent.
>
>> To stick with (and get factory / monitoring
>> benefits of) PooledObjectFactory / PooledObjects, I need to create a
>> version of DefaultPooledObject that wraps SoftReferences and these
>> have to be mutable - i.e., when an instance is returned a new soft
>> reference is created and stored in the pool, but we want to maintain
>> PooledObject state. To do this, I need to be able to recognize the
>> returning object. I could do this by searching the pool, but that
>> will cost something. On the other hand, the lack of search now
>> means returnObject is not idempotent (like it is in the rest of the
>> 2.0 pools). Multiple returns will put multiple soft references to
>> the same object in the pool.
>>
>> So, I would appreciate some feedback on the following options:
>>
>> 1) Add a search for the returning object and create a
>> PooledSoftReference subclass of DefaultPooledObject within
>> SoftReferencePool to be stored in the pool.
>>
>> 2) Keep PoolableObjectFactory just for this pool and leave it alone,
>> adding a warning to returnObject (not a new issue, just different
>> from other 2.0 pools).
> I think the benefits of the monitoring justify adding the search so my
> preference is for option 1.
Drat, I thought I was going to get away with 2) - he he. I will
plow ahead with 1 :)
Phil
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
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...
Posted by Mark Thomas <ma...@apache.org>.
On 03/08/2013 17:15, Phil Steitz wrote:
> On 7/30/13 9:16 AM, Phil Steitz wrote:
>> I have started working on this. Should have something to commit at
>> least for GOP in the next day or two.
>
> I am stuck on SoftReferenceObectPool.
:(
> I have been able to handle
> everything else collapsing down to just Pooled(Keyed)ObjectFactory /
> Base(Keyed)ObjectPool.
Excellent.
> To stick with (and get factory / monitoring
> benefits of) PooledObjectFactory / PooledObjects, I need to create a
> version of DefaultPooledObject that wraps SoftReferences and these
> have to be mutable - i.e., when an instance is returned a new soft
> reference is created and stored in the pool, but we want to maintain
> PooledObject state. To do this, I need to be able to recognize the
> returning object. I could do this by searching the pool, but that
> will cost something. On the other hand, the lack of search now
> means returnObject is not idempotent (like it is in the rest of the
> 2.0 pools). Multiple returns will put multiple soft references to
> the same object in the pool.
>
> So, I would appreciate some feedback on the following options:
>
> 1) Add a search for the returning object and create a
> PooledSoftReference subclass of DefaultPooledObject within
> SoftReferencePool to be stored in the pool.
>
> 2) Keep PoolableObjectFactory just for this pool and leave it alone,
> adding a warning to returnObject (not a new issue, just different
> from other 2.0 pools).
I think the benefits of the monitoring justify adding the search so my
preference is for option 1.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
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...
Posted by Phil Steitz <ph...@gmail.com>.
On 7/30/13 9:16 AM, Phil Steitz wrote:
> I have started working on this. Should have something to commit at
> least for GOP in the next day or two.
I am stuck on SoftReferenceObectPool. I have been able to handle
everything else collapsing down to just Pooled(Keyed)ObjectFactory /
Base(Keyed)ObjectPool. To stick with (and get factory / monitoring
benefits of) PooledObjectFactory / PooledObjects, I need to create a
version of DefaultPooledObject that wraps SoftReferences and these
have to be mutable - i.e., when an instance is returned a new soft
reference is created and stored in the pool, but we want to maintain
PooledObject state. To do this, I need to be able to recognize the
returning object. I could do this by searching the pool, but that
will cost something. On the other hand, the lack of search now
means returnObject is not idempotent (like it is in the rest of the
2.0 pools). Multiple returns will put multiple soft references to
the same object in the pool.
So, I would appreciate some feedback on the following options:
1) Add a search for the returning object and create a
PooledSoftReference subclass of DefaultPooledObject within
SoftReferencePool to be stored in the pool.
2) Keep PoolableObjectFactory just for this pool and leave it alone,
adding a warning to returnObject (not a new issue, just different
from other 2.0 pools).
Phil
>
> 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, markt@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
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...
Posted by Phil Steitz <ph...@gmail.com>.
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, markt@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
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...
Posted by Phil Steitz <ph...@gmail.com>.
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, markt@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
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...
Posted by Mark Thomas <ma...@apache.org>.
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, markt@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
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...
Posted by James Carman <ja...@carmanconsulting.com>.
I like the sound of that!
On Mon, Jul 29, 2013 at 2:42 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Mon, Jul 29, 2013 at 1:56 PM, Phil Steitz <ph...@gmail.com> wrote:
>
>> On 7/24/13 1:06 PM, Mark Thomas wrote:
>> > On 24/07/2013 21:01, markt@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.
>>
>
> This all sounds good at first glance.
>
> The less code I, as a user, have to understand and write, the better.
>
> If that takes care of 80% of user stories, great. For the rest, we can add
> bells and whistles, on top of what will likely be a simpler and cleaner
> base.
>
> Gary
>
>
>> Phil
>> >
>> > Mark
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
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...
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Jul 29, 2013 at 1:56 PM, Phil Steitz <ph...@gmail.com> wrote:
> On 7/24/13 1:06 PM, Mark Thomas wrote:
> > On 24/07/2013 21:01, markt@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.
>
This all sounds good at first glance.
The less code I, as a user, have to understand and write, the better.
If that takes care of 80% of user stories, great. For the rest, we can add
bells and whistles, on top of what will likely be a simpler and cleaner
base.
Gary
> Phil
> >
> > Mark
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory