From jdo-dev-return-5258-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Sat Nov 11 09:23:48 2006 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 92583 invoked from network); 11 Nov 2006 09:23:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Nov 2006 09:23:48 -0000 Received: (qmail 55695 invoked by uid 500); 11 Nov 2006 09:23:59 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 55678 invoked by uid 99); 11 Nov 2006 09:23:58 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Nov 2006 01:23:58 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [216.148.213.132] (HELO smtp.mailix.net) (216.148.213.132) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 11 Nov 2006 01:23:44 -0800 Received: from [192.168.8.8] (helo=localhost) by smtp.mailix.net with asmtp (Exim 4.24-H) id 1Gip5F-0001IX-3a; Sat, 11 Nov 2006 01:23:29 -0800 Received: from 39.118-240-81.adsl-dyn.isp.belgacom.be (39.118-240-81.adsl-dyn.isp.belgacom.be [81.240.118.39]) by webmail.jpox.org (IMP) with HTTP for ; Sat, 11 Nov 2006 01:23:19 -0800 Message-ID: <1163236999.45559687563db@webmail.jpox.org> Date: Sat, 11 Nov 2006 01:23:19 -0800 From: Erik Bengtson To: JDO Expert Group , Apache JDO project References: <4553C51D.4050308@sun.com> <9877BD33-0642-4E15-B354-62A9F9D53C0A@SUN.com> In-Reply-To: <9877BD33-0642-4E15-B354-62A9F9D53C0A@SUN.com> MIME-Version: 1.0 User-Agent: Internet Messaging Program (IMP) 3.2.3 X-Originating-IP: 81.240.118.39 X-SA-Exim-Mail-From: erik@jpox.org Subject: Re: Minutes: JDO TCK Conference Call Friday, Nov 10, 9 am PST Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SA-Exim-Version: 3.1 (built Thu Oct 23 13:26:47 PDT 2003) X-SA-Exim-Scanned: No; Unknown failure X-uvscan-result: clean (1Gip5F-0001IX-3a) X-Virus-Checked: Checked by ClamAV on apache.org > 2. Suggestion for new PMF setting javax.jdo.ClassLoader > > From Erik: When a JDBC driver is not loaded by the classloader ruled > by JDO, there is no standard trick to make it work besides > implementing the object factory (DriverManager is not designed for > complex classpath). In JPOX, we have implemented a PMF setting where > users can specify a ClassLoader for general use (it is the last one > in search order). Do you think we could make this in the standard? > > javax.jdo.ClassLoader which takes a java.lang.ClassLoader as value. > > We assume that the intended use is for applications that specify the > property javax.jdo.javax.jdo.option.ConnectionDriverName and > class.forName on this property value results in class not found. So > the jdbc driver is never registered with DriverManager. > This is the most common case I remember that needs to lookup to the user defined classloader. > Questions: Why doesn't the ContextClassLoader work? Here is the scenario: ClassLoader A loads libraries like JDBC drivers. ClassLoader B loads persistent classes. ClassLoader C loads persistent code. (delegates to B, C and D) (has a reference to A) ClassLoader D loads libraries like JDO. ClassLoader E loads JPOX. (delegates to D) ClassLoader F is used by GUI . App starts with Thread 1 that uses classloader F, it switch to class loader C (creates the pmf), but quickly falls back to F. After that, the current context loader is F. The only workaround is giving the reference of A to the PMF when created. > usage in a managed environment? No, this is not the main case. Here people should use the datasource provided by the app servers