commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodney Waldhoff <rwaldh...@apache.org>
Subject RE: [Pool] What's left for a release?
Date Tue, 22 Apr 2003 18:12:20 GMT
Ok, but you may not like all my answers.

Regarding <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19192>, I
think I'm reasonably comfortable with making this change before the 2.0
release--this simply unsyncs the factory's makeObject method, which
shouldn't need to be locked by the pool anyway.  Also, addObject stands in
isolation--none of the other pool methods invoke it, so this will only
impact those who "prepopulate" or otherwise add things to the pool
manually.  If struts doesn't do that, then maybe David will be more
comfortable with the change.  If it'll keep everyone happy, maybe we
should do a 2.0 release without that change and immediately follow it up
this change (either as a 2.0.1 or SNAPSHOT release).

Regarding "allowing advanced use of [GenericObjectPool] by subclassing", I
happen to have posted an article just yesterday (see
<http://radio.weblogs.com/0122027/stories/2003/04/21/areConcreteParentClassesACodeSmell.html>)
that argues against concrete parent types. Honestly, I think the pool API
would be better served by some refactoring to better allow customization
via composition rather than inheritance.  The current design offers one
type of partitioning--separating the pool management from the object
lifecycle--but fails to support all the axes and degrees of variation that
are desired.  I have some notes that discuss this in greater detail that I
had originally intended to post as "proposal", but it began to seem like
it'd be easier just to check it in an let someone veto if they way.
Following the 2.0 release I'll try to do one or the other.

- Rod <http://radio.weblogs.com/0122027/>

On Tue, 22 Apr 2003, Gary Gregory wrote:

> Rodney,
>
> I see your name as the author for GenericObjectPool. Do you have any
> thoughts to share with us on this topic?
>
> Thanks,
> Gary
>
> -----Original Message-----
> From: Gary Gregory [mailto:ggregory@seagullsw.com]
> Sent: Tuesday, April 22, 2003 10:28 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [Pool] What's left for a release?
>
> David,
>
> Well, here we could split this into two issues. I do not like (1) and I am
> in favor for (2).
>
> (1) Which exact one field in GenericObjectPool would we need to change to
> protected access to address our current problem? We could make this one
> field protected in 2.0. We could then create our own subclass and define the
> behavior we need. You would end up with GenericObjectPool that has one ivar
> protected and all others private, which is oddly inconsistent and needs to
> be explained in the docs. The next time a problem shows up which /could/
> have been solved with a subclass, we are back to where we started: You could
> subclass if only field f was protected instead of private. I claim this is
> not the way to go.
>
> (2) GenericObjectPool is a nice re-usable class, at runtime. As the Javadoc
> states it is "configurable". My claim is that full reusability would be
> better served by allowing advanced use of the class via subclassing.
>
> Here, http://jakarta.apache.org/commons/pool/, states: "A generic object
> pool interface that clients and implementors can use to provide easily
> interchangable pooling implementations." (Webmaster, interchangable ->
> interchangeable.)
>
> Well, we would like to be implementing our own pool to customize behavior in
> GenericObjectPool, but we cannot. Hence the request to simply make fields
> and methods that are now private protected. This would allow subclassing to
> work, always. Why not solve this problem once?
>
> Thanks for taking the time to consider this issue, BTW.
>
> Gary
>
> PS: I cannot tell how many times this happens with third party code... GG.
>
> -----Original Message-----
> From: David Graham [mailto:dgraham1980@hotmail.com]
> Sent: Tuesday, April 22, 2003 10:00 AM
> To: commons-dev@jakarta.apache.org
> Subject: RE: [Pool] What's left for a release?
>
> Specifically, which fields do you want protected access for that you can't
> get to via accessors?
>
> David
>
>
>
> >From: Gary Gregory <ggregory@seagullsw.com>
> >Reply-To: "Jakarta Commons Developers List"
> ><commons-dev@jakarta.apache.org>
> >To: 'Jakarta Commons Developers List' <commons-dev@jakarta.apache.org>
> >Subject: RE: [Pool] What's left for a release?
> >Date: Tue, 22 Apr 2003 11:46:55 -0400
> >
> >Hello,
> >
> >Could you address why doing (2) only be an issue?
> >
> >It certainly would be fast task, I am volunteering of course!
> >
> >Thanks,
> >Gary
> >
> >-----Original Message-----
> >From: David Graham [mailto:dgraham1980@hotmail.com]
> >Sent: Tuesday, April 22, 2003 8:44 AM
> >To: commons-dev@jakarta.apache.org
> >Subject: RE: [Pool] What's left for a release?
> >
> >-1 on changing this for 2.0.  Struts needs this release soon.
> >
> >David
> >
> >
> > >Hello,
> > >
> > >Could we address http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19192
> > >for
> > >2.0?
> > >
> > >This is not a simple issue but it is very important for our application.
> >I
> > >see two issues raised in GenericObjectPool by 19192:
> > >
> > >(1) What is the "correct" or desired default behavior? If we need a
> >release
> > >very soon (to satisfy a Struts dependency for example), this would argue
> > >for
> > >not changing the locking behavior without some serious unit tests added
> >in
> > >this department. So, if time is of the essence, don't touch it, and we
> >can
> > >discuss it post-2.0.
> > >
> > >(2) If we consider that a goal for the class GenericObjectPool is that it
> > >be
> > >customizable on top of "configurable" (Javadoc comment), by which I mean
> > >extendable/subclassable, then we should change the protection of fields
> >and
> > >methods from private to protected to allow for this to happen. This is
> >not
> > >the first time that we have seen the suggestion that a feature/bug could
> > >have been addressed by subclassing but that in fact could not due to
> > >field/method protection. (I am leaving aside the fact that one can change
> > >any code in [pool] and recompile).
> > >
> > >Thoughts?
> > >
> > >Gary
> > >
> > >-----Original Message-----
> > >From: James Mitchell [mailto:jmitchell@apache.org]
> > >Sent: Thursday, April 17, 2003 4:16 AM
> > >To: jakarta-commons-dev@apache.org
> > >Subject: [Pool] What's left for a release?
> > >
> > >Initial search in bugzilla for pool turned up 3 bugs (ok, 2 bugs and 1
> > >Enhancement).  The 2 bugs that were there have patches available.
> > >
> > >I was wondering if there were any specific reasons (other than
> > >time/resources)
> > >that those patches had not been committed.
> > >
> > >We are pushing for a RC2 over in the Struts camp and we depend on a new
> > >release of Pool.  I'd like to help with this if I can.
> > >
> > >Your thoughts?
> > >
> > >
> > >--
> > >James Mitchell
> > >Software Developer/Struts Evangelist
> > >http://www.open-tools.org
> > >
> > >
> > >
> > >
> > >---------------------------------------------------------------------
> > >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >_________________________________________________________________
> >MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.
> >http://join.msn.com/?page=features/virus
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message