Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 84109 invoked by uid 500); 6 Aug 2001 15:09:03 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 84089 invoked from network); 6 Aug 2001 15:09:02 -0000 Message-ID: <3B6EB2FB.FE50912E@apache.org> Date: Mon, 06 Aug 2001 11:08:43 -0400 From: Berin Loritsch X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: Potential Classloader bug References: <3B694C02.184CDDA4@apache.org> <3B6EAC7A.D447FDA9@anyware-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Sylvain Wallez wrote: > > Shouldn't there be a mean in Avalon to store this "application root > ClassLoader" and use it in selected places, like JDBC driver loading ? > This will allow the JdbcDataSource to be loaded in the same > ClassLoader as with the "force-load" parameter. Cocoon stores the Application Root Classloader in each threads Context Classloader so that we can execute the following snippet to get it: Thread.currentThread().getContextClassLoader(); The issue with the JDBC driver was the the loadClass(name) function does not resolve the class--which is essential to dynamically installing the driver in the JDBC DriverManager. I solved the problem by using the JDK1.2 (or is it 1.3 specific) method: Class.forName(name, true, classLoader); What this does is load a class with the specified classloader, and the "true" parameter tells the ClassLoader to resolve the class. --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org