Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Pool] What's left for a release?
Date: Tue, 22 Apr 2003 13:44:14 -0400
Message-ID: <9C5166762F311146951505C6790A9CF8346401@US-VS1.corp.mpi.com>
Thread-Topic: [Pool] What's left for a release?
thread-index: AcMI9cSzUnmqx1UyS0CtPe8Q/8dVsgAAE2nQ
From: "Shapira, Yoav" <Yoav.Shapira@mpi.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>


Howdy,
I'll jump in as a simple user of this code but having faced this probl=
em
numerous times as a contributor on several jakarta and for-profit
projects.

>(1) Which exact one field in GenericObjectPool would we need to chang=
e
to
>protected access to address our current problem? We could make this o=
ne
>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 on=
e
ivar
>protected and all others private, which is oddly inconsistent and nee=
ds
to

I don't think it's oddly inconsistent.  In fact, I think it's consiste=
nt
with the practice of making everything private until an overriding
requirement comes up.  However, I agree with you this approach is
suboptimal.

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

I agree this would be a better long-term solution conceptually.  Two
points though:
- Not all private fields should automatically be made protected.  Only=

those fields likely to be modified by a subclass need be made protecte=
d.

- There's a conflicting requirement here, which is a speedy release to=

satisfy struts dependencies.

Given the speedy release requirement, I would tend to say keep it as
stable as possible, and make the private->protected transition one of
the top items for the next release.  Of course that's easy for me to s=
ay
as I don't need the modifications right now.  However, I would
anticipate a fairly quick (< 4 weeks) Pool 2.1 release with mainly the=
se
modifications.

Yoav Shapira
Millennium ChemInformatics


This e-mail, including any attachments, is a confidential business com=
munication, and may contain information that is confidential, propriet=
ary and/or privileged.  This e-mail is intended only for the individua=
l(s) to whom it is addressed, and may not be saved, copied, printed, d=
isclosed or used by anyone else.  If you are not the(an) intended reci=
pient, please immediately delete this e-mail from your computer system=
 and notify the sender.  Thank you.


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