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 15:40:42 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message