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/
