Kathey Marsden wrote:
I am moving this to derby-dev as I think my new questions are more
appropriate for this list.
Oyvind's suggestion to make a DerbyURLClassLoader to filter out the
derby classes from the parent class loader all seems to be working ok
(with some very minimal testing).
David W. Van Couvering wrote (for Binod):
Make sure that there is only one URL classloader instance that has
access to the derby jar files. And make sure that whenever a code
accesses the datasource, it always go thru newDataSource method, then
yes, it should work.
I just want to verify that this just means that my app should use the
same loader if it needed to get another datasource for say shutting down
the database. Other applications should be able to use their own
DerbyURLClassLoaders to access Derby as long as they are accessing
different databases, right?
I think "as long as they are accessing different Derby
systems/instances" is more precise to say than different "databases".
p.s: This is all assuming that derby code doent do any other interesting
classloader mechanism inside :-). For example, it can use Thread's
context classLoader to load some other part of derby that might break.
Is there anything like Binod describes in Derby that might cause
problems (e.g. code for loading generated byte code, loading databases
from jars or aggregates) ?
Classloaders which use the default parent classloader should not pose a
problem. It's that Thread's context classloader which is spooky. I found
references to getContextClassLoader in three files:
client/org/apache/derby/client/am/GetResourceInputStreamAction.java
engine/org/apache/derby/impl/services/reflect/ReflectClassesJava2.java
engine/org/apache/derby/impl/io/CPFile.java
I haven't looked at what's being done with that classloader in those
files, so I can't really say whether this is an issue.
One other issue I have encountered is that I am not sure how to handle
the derby error log (derby.log). The configuration for this is only
provided with System properties or entries in the derby.properties file
which would affect other apps. How do I create my own isolated error
log with out clobbering the error logs of other apps or having them
clobber mine?
Hm... create your own java.lang.System and load it with the
DerbyURLClassLoader? ;o) I'm joking, of course. Are the system
properties read only once, during initialization of a Derby instance? If
so, you could modify the System properties before loading the next Derby
instance. Of course, that requires synchronization and doesn't work in
an app server with applications that don't know about each other. I
don't have a good workaround for you here. The best thing would be to
have some other way to set these properties than through the System
properties, but if that's not available today...
--
Oyvind Bakksjo
Sun Microsystems, Database Technology Group
Trondheim, Norway
http://weblogs.java.net/blog/bakksjo/
