db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: context classloader versus default classloader
Date Wed, 23 Nov 2005 22:51:18 GMT


Oyvind.Bakksjo@Sun.COM wrote:
> David W. Van Couvering wrote:
> 
> 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.
>

yes, OK

>> 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.

Well, I was going to test this, because I wasn't sure how this worked. 
But what you say makes sense, thanks.

Still ruminating on this...

David


Mime
View raw message