commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [Pool] What's left for a release?
Date Tue, 22 Apr 2003 18:53:55 GMT
Why, your answers are very thoughtful! :-)

<Rodney>Regarding [snip] 19192 [snip] 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).</Rodney>

Obviously, this would be fine, the sooner the better for us. The less we
have to patch and custom build, the better, But WRT:

<Rodney>Regarding "allowing advanced use of [GenericObjectPool] by
subclassing" [snip]</Rodney>

This is a very intersting topic for discussion! But let me stay focused on
the job at hand (for us, using the code): it does not solve the problem we
have today with today's release or CVS code base. Yes, if the code is
refactored along newly discovered axes of desired usability, we will be able
use a future release as is. I still cannot get the pool to work like I want
today with the only tool I want to use: subclassing (Other tool: I really do
not want to be _forced_ to patch the pool source code itself and rebuild).

My general argument I think is still valid and does not in any way
contradict the design goals you may choose for future releases. There will
always be unforeseen usage patterns that are not (I do not want to use the
word "aspect" here) addressed by some configurable axes. 

Furthermore, what if I do want to tweak the behavior just so to either fix
or specialize a behavior. Why should I be *explicitly* disallowed this
option? What is the point? 

For every release, you could get messages like: "You know, we were trying to
pool Foo objects within the Bar system and we subclasses XPool this way and
that way. Wouldn't it be nice if XPool supported this in the next release?"

Today, you may not get messages like the above. Instead, the pools might be
used sub-optimally or painfully patched (we have done this in the past), and
this list will be peppered with messages for requests for features A, B or C
and the answer, which HAS BEEN given several times: "Just subclass XPool and
you'll be fine" can be given without the answer being: "Uh, I would subclass
XPool, but everything is private..."

So, why not make things simple and allow subclassing? This seems like a
reasonable request to me. Inversely, why disallow subclassing? This would
seem to send the wrong message: "You can only use our classes /this/ way."
Cynicism On: "Sorry, no subclassing, wouldn't want to shoot yourself in the
foot now would you?"

Gary

-----Original Message-----
From: Rodney Waldhoff [mailto:rwaldhoff@apache.org] 
Sent: Tuesday, April 22, 2003 11:12 AM
To: Jakarta Commons Developers List
Subject: RE: [Pool] What's left for a release?

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/areConcreteParentClasse
sACodeSmell.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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message