You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2013/07/29 20:42:11 UTC
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...
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
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