commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
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:42:11 GMT
On Mon, Jul 29, 2013 at 1:56 PM, Phil Steitz <phil.steitz@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message