[EMAIL PROTECTED] 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
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
