On Mon, Jul 29, 2013 at 1:56 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
> On 7/24/13 1:06 PM, Mark Thomas wrote: > > On 24/07/2013 21:01, ma...@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-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@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
