I like the sound of that!
On Mon, Jul 29, 2013 at 2:42 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
