Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C27BADA52 for ; Mon, 30 Jul 2012 20:17:25 +0000 (UTC) Received: (qmail 45967 invoked by uid 500); 30 Jul 2012 20:17:25 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 45735 invoked by uid 500); 30 Jul 2012 20:17:25 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 45726 invoked by uid 99); 30 Jul 2012 20:17:25 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jul 2012 20:17:25 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [80.12.242.68] (HELO smtpout.wanadoo.co.uk) (80.12.242.68) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jul 2012 20:17:17 +0000 Received: from mail.homeinbox.net ([2.24.218.1]) by mwinf5d49 with ME id gkGv1j00A02Pqcq03kGvGb; Mon, 30 Jul 2012 22:16:56 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.homeinbox.net (Postfix) with ESMTP id 357ECB22002 for ; Mon, 30 Jul 2012 21:16:55 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at homeinbox.net Received: from mail.homeinbox.net ([127.0.0.1]) by localhost (mail.homeinbox.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rr1qHoMSDaN for ; Mon, 30 Jul 2012 21:16:50 +0100 (BST) Received: from [192.168.23.9] (study03.dev.local [192.168.23.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.homeinbox.net (Postfix) with ESMTPSA id 456A2B22001 for ; Mon, 30 Jul 2012 21:16:50 +0100 (BST) Message-ID: <5016EBB0.80008@apache.org> Date: Mon, 30 Jul 2012 21:16:48 +0100 From: Mark Thomas User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Commons Developers List Subject: Re: [pool] Question / potential improvement on KeyedObjectPool References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On 30/07/2012 21:07, Liviu Tudor wrote: > * Findbugs: indeed, some of the findbugs warnings are not entirely correct > -- and we should probably look at using the Findbugs annotations to > manually annotate the ones which we know to actually be false alarms? > There were also a couple related to performance suggestions which were > valid -- so as per your suggestion I'm going to submit a patch for those. > Regarding the false alerts in FindBugs -- there are 2 ways to proceed with > "removing" these alerts: > ** one is as I suggested above to enable the findbugs annotations in the > pom and manually annotate those 2 methods to remove the findbugs checks > ** second one is to manually remove the findbugs checks via a > findbugs-exclude.xml from the suite of findbugs tests run. > Not sure which one do we prefer in Commons? (or more to the point in this > case?) Personally, I prefer findbugs-exclude.xml since that doesn't pollute the build for folks who have no interest in FindBugs. > * The unit test thing though puzzles me as I keep constantly get this : > > Results : > > Failed tests: > testConstructors(org.apache.commons.pool.impl.TestGenericKeyedObjectPool): > expected:<4> but was:<2> > > testConstructors(org.apache.commons.pool.impl.TestGenericKeyedObjectPoolFac > tory): expected:<4> but was:<2> > > testConstructors(org.apache.commons.pool.impl.TestGenericObjectPoolFactory) > : expected:<4> but was:<2> > > > When running the TestGenericKeyedObjectPool! I'm running them on a Mac -- > but checked them on a win machine with the same result. Looking closer, it > seems to be down to the fact that the maxIdle is set to be lower than > midIdle -- and there is logic in the GenericKeyedObjectPool to return > maxIdle in such cases. I'm not sure therefore if the default values in the > unit test are wrong or the logic in the GenericKeyedObjectPool is wrong? > I'm happy to change the assert's in the unit test and submit a patch -- > but I would like this validated by someone who has been involved > previously in this piece of code? > Also, I would be curious to know whether the tests are indeed passing ? They fail for me to. Odd. I would have expected a CI nag about that. 'svn log' and 'svn blame' can be very useful when determining why code is the way it is. In this case they point to POOL-212 and it is indeed the unit tests that are wrong. > * Last but not the least, I see the pom references junit-4.10 but the unit > tests are still based on the old junit-3.8 looking at it. Worth to change > these to annotations a la junit-4? Not for Pool 1.5. The target Java version is < 1.5. Not sure it is worth it for 1.6 (and it easier to keep the 1.5.x and 1.6.x in sync if it is just generics that is the difference). For Pool 2.x I don't have a strong preference. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org