db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oyvind.Bakk...@Sun.COM
Subject Re: Question about using URLClassLoader and Derby
Date Thu, 10 Nov 2005 15:23:38 GMT
Kathey Marsden wrote:
> Super neat!  To summarize:
> 
> I can keep other Derby versions loaded from interfering with my app  by
> creating a  DerbyURLClassLoader that overrides the loadClass method to
> filter out any Derby classes in the parent class loader.
> 
> I can prevent my app from interfering with other Derby versions  by
> loading Derby in a separate DerbyURLClassLoader and creating a
> DataSource from there that I use for all my connections as described in
> my original mail. 
> 
> I have a completely isolated environment with regard to Derby.  Because
> JDBC provides a single entry point at the DataSource, I don't have to
> understand the overall ClassLoader hierarchy or otherwise be a
> ClassLoader expert.  Does anyone see any holes here?   

As long as the code you have using Derby is accessing Derby objects 
through the JDBC interfaces/classes, everything should be fine. If, 
however you have code explicitly referencing Derby class names (whether 
it is EmbedStatement, EmbeddedDataSource etc.), you should be aware that 
a class X loaded with class loader A is not the same class as a class X 
loaded with class loader B (class loaders are name spaces). Code which 
explicitly references Derby classes must be loaded with the same class 
loader as the Derby classes themselves, otherwise you'll get strange 
exceptions.

But as said, when your client code simply uses the JDBC 
interfaces/classes, there should be no problems.

-- 
Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway
http://weblogs.java.net/blog/bakksjo/

Mime
View raw message