commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <dgraham1...@hotmail.com>
Subject RE: [Pool] What's left for a release?
Date Tue, 22 Apr 2003 18:22:20 GMT
Struts does not use commons-pool directly, we inherit the dependency from 
our use of DBCP.  If you're comfortable with the change and it won't break 
DBCP (which we also need a release of), then I'm fine with it.

We still haven't heard what variables subclasses need access to that don't 
already have accessors.

David



>From: Rodney Waldhoff <rwaldhoff@apache.org>
>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:12:20 -0700 (PDT)
>
>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
>


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail


---------------------------------------------------------------------
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