db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oyvind.Bakk...@Sun.COM
Subject Re: context classloader versus default classloader
Date Wed, 23 Nov 2005 11:52:50 GMT
David W. Van Couvering wrote:
> The concern I have is that DatabaseClasses.loadApplicationClass() uses 
> the thread context classloader, and if the class is not found there (or 
> there is no context classloader), only then does it use the default 
> classloader.
> Let's say I'm able to create a classloader whose search path only 
> includes specific derby jar files (to avoid the issues of mixed versions 
> of Derby).

To avoid those issues, you need to make sure that your classloader does 
not delegate loading of Derby classes to its parents. You don't need to 
restrict the search path of your classloader to *only* derby jar files.

> Then let's say I try to make use of this when getting connections:
> URLClassLoader cl = new MyClassLoader()
> EmbeddedDataSource ds = 
> (EmbeddedDataSource)(cl.loadClass("org.apache.derby.jdbc.EmbeddedDataSource").newInstance())

If you write code like this, the declaration of ds causes a load of 
EmbeddedDataSource through the default classloader. If this classloader 
cannot load Derby, you will get an exception before getting to 
cl.loadClass(). If it *is* able to load Derby, ds will be of a different 
class than the one loaded with cl.loadClass(), so the assignment will 
throw a ClassCastException.

> Connection conn = ds.getConnection(...);
> This effectively sets the default classloader for EmbeddedDataSource 
> (and all its dependent classes) to be MyClassLoader.

Yes, the default classloader for any class is the classloader it was 
loaded with.

Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway

View raw message