Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 19618 invoked from network); 8 Jul 2010 00:48:14 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Jul 2010 00:48:14 -0000 Received: (qmail 24538 invoked by uid 500); 8 Jul 2010 00:48:14 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 24403 invoked by uid 500); 8 Jul 2010 00:48:13 -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 24395 invoked by uid 99); 8 Jul 2010 00:48:13 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jul 2010 00:48:13 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rob.heittman@solertium.com designates 209.85.212.43 as permitted sender) Received: from [209.85.212.43] (HELO mail-vw0-f43.google.com) (209.85.212.43) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jul 2010 00:48:04 +0000 Received: by vws4 with SMTP id 4so327175vws.30 for ; Wed, 07 Jul 2010 17:47:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.98.146 with SMTP id q18mr3759444vcn.253.1278550063236; Wed, 07 Jul 2010 17:47:43 -0700 (PDT) Received: by 10.220.193.75 with HTTP; Wed, 7 Jul 2010 17:47:43 -0700 (PDT) X-Originating-IP: [96.238.67.243] Date: Wed, 7 Jul 2010 20:47:43 -0400 Message-ID: Subject: Behavior of DBCP 1.4 BasicDataSource setDriverClassLoader(...) From: Rob Heittman To: dev@commons.apache.org Content-Type: multipart/alternative; boundary=0016e646410258c5eb048ad5a2d8 X-Virus-Checked: Checked by ClamAV on apache.org --0016e646410258c5eb048ad5a2d8 Content-Type: text/plain; charset=ISO-8859-1 Hi all, It seems to me that the 1.4 behavior of BasicDataSource with regard to setDriverClassLoader(...) is slightly off. In my case -- using this to enable DBCP to work better under some OSGi environments -- it doesn't have the desired effect. In createConnectionFactory() we have, essentially if (driverFromCCL == null) { // use DriverManager, which doesn't respect driverClassLoader driver = DriverManager.getDriver(url); } else { // ... use the CCL to make our own Driver ... } It's simple enough in my project to override createConnectionFactory(), but wouldn't it be more predictable to do something like this? if (driverClassLoader !=null) { // ... use driverClassLoader to make our own Driver ... } else if (driverFromCCL == null) { // use a method that doesn't respect driverClassLoader driver = DriverManager.getDriver(url); } else { // ... use the CCL to make our own Driver ... } Alternatively, a couple stanzas higher, we could set driverFromCCL if driverClassLoader is used, which would trigger the correct behavior in this (unmodified) section. It seems like if somebody goes to the trouble to setDriverClassLoader(...) they expect it to be used to load driver classes. (I did) If wiser heads agree, happy to send a patch. - Rob --0016e646410258c5eb048ad5a2d8--