Return-Path: 
 <commons-dev-return-87011-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 38859 invoked from network); 29 Mar 2006 03:00:18 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 29 Mar 2006 03:00:18 -0000
Received: (qmail 56606 invoked by uid 500); 29 Mar 2006 03:00:14 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 56514 invoked by uid 500); 29 Mar 2006 03:00:13 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 56503 invoked by uid 99); 29 Mar 2006 03:00:13 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Mar 2006 19:00:13 -0800
X-ASF-Spam-Status: No, hits=1.3 required=10.0
	tests=RCVD_IN_BL_SPAMCOP_NET,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (asf.osuosl.org: domain of sandymac@gmail.com designates
 64.233.182.185 as permitted sender)
Received: from [64.233.182.185] (HELO nproxy.gmail.com) (64.233.182.185)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 28 Mar 2006 19:00:12 -0800
Received: by nproxy.gmail.com with SMTP id n28so78309nfc
        for <commons-dev@jakarta.apache.org>;
 Tue, 28 Mar 2006 18:59:51 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=k5LkKAjpiPPiD2QWj9tJgjjCNtxllivURUjT2BEOM7AgdI66M1T6RqG15jZ+G2z1LCiYN6LQm2jfHkAE9ulLnHkrDIIcKoPs9TwUCJQ9yk1wArbUseuBCc5tBY5Ca4xC6JZJ8VGdICRbhPkkhNWo1UnD/+IUZnSFKp0gXcuzcRo=
Received: by 10.48.231.3 with SMTP id d3mr122874nfh;
        Tue, 28 Mar 2006 18:59:51 -0800 (PST)
Received: by 10.48.207.5 with HTTP; Tue, 28 Mar 2006 18:59:51 -0800 (PST)
Message-ID: <6bde122b0603281859i726adc28h6bb4b196a241495d@mail.gmail.com>
Date: Tue, 28 Mar 2006 21:59:51 -0500
From: "Sandy McArthur" <sandymac@apache.org>
Sender: sandymac@gmail.com
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Subject: Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool
 1.3 based on 1.3-rc4]
In-Reply-To: <8a81b4af0603281832w1f1bafecwa718ebe73f70b100@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <6bde122b0603262315u6644d11bl9c5602082a029faf@mail.gmail.com>
	 <8a81b4af0603271843j74068706hc4505c64574e3521@mail.gmail.com>
	 <1143581174.5185.0.camel@knossos.elmet>
	 <8a81b4af0603281832w1f1bafecwa718ebe73f70b100@mail.gmail.com>
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

On 3/28/06, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 3/28/06, robert burrell donkin <robertburrelldonkin@blueyonder.co.uk> =
wrote:
> > On Mon, 2006-03-27 at 19:43 -0700, Phil Steitz wrote:
> > > <snip/>
> > > > * testPooling: This test method passes when you run it by itself. I=
t
> > > > fails because while it looks like it's written to handle either a F=
IFO
> > > > or a LIFO pool implementation it doesn't if the GenericObjectPool
> > > > backing Dbcp has more than 2 idle connections. When the test is run
> > > > after other tests the GOP contains 4 idle connections. With a LIFO =
the
> > > > most recently returned is the first one borrowed so it doesn't matt=
er
> > > > how many idle connections already exist at the start of the test.
> > > > Since GOP is now a FIFO the test fails because is incorrectly assum=
es
> > > > that a recently returned connection will be the next one borrowed. =
IMO
> > > > testPooling should be removed as it really testing Pool's behavior =
and
> > > > not Dbcp's behavior.
> > >
> > > Yes.  This is bad and I agree this test case should be removed, as it
> > > depends on the implementation of the underlying pool, which is not
> > > part of [dbcp].  If there are no objections, I will remove this test
> > > case.
> >
> > or replace with a mock pool implementation (if possible)
>
> This is an interesting idea.  Would appreciate suggestions on how
> exactly to do this.

I haven't dug into Dbcp code but I think the GenericObjectPool is deep
within Dbcp as an internal data structure and I'd be surprised if it
let you specify a specific pool implementation.

Even if you do mock the pool, the test would be testing the behavior
of the mock pool as called through Dbcp. I think any interesting
interaction with the GOP would be implicitly tested by other unit
tests.

--
Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

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