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 01:22:19 GMT
The concern I have is that DatabaseClasses.loadApplicationClass() uses 
the thread context classloader, and if the class is not found there (or 
there is no context classloader), only then does it use the default 

Let's say I'm able to create a classloader whose search path only 
includes specific derby jar files (to avoid the issues of mixed versions 
of Derby).

Then let's say I try to make use of this when getting connections:

URLClassLoader cl = new MyClassLoader()
EmbeddedDataSource ds = 
Connection conn = ds.getConnection(...);

This effectively sets the default classloader for EmbeddedDataSource 
(and all its dependent classes) to be MyClassLoader.

What I am concerned about is that there is all this code in the Derby 
engine that calls DatabaseClasses.loadApplicationClass().  It looks like 
this is used to load classes for VTIs and Java stored procedures (it's 
hard to tell) as well as a number of other things I'm not clear on.  If 
any of these classes are Derby classes (for instance internal VTIs) then 
it would seem that my attempt to correctly load Derby classes from the 
right jar files will be thwarted.

Probably the right thing for me to do is test this, but if you have any 
observations about this that might guide me it would be much appreciated.



Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
>>Hi.  I am a little confused between two different "current classloaders"
>>that are available to appication code:
>>this.getClass().getClassLoader() -- what I call the "default classloader"
>>Thread.currentThread.getContextClassLoader() -- what I call the "context
>>When I am creating my own classloader, I want to identify the parent
>>classloader.  Which one of these should I use?  I noticed that the
>>engine code uses the context classloader to load application classes,
>>but sets the default classloader to be its parent when creating a
>>classloader for loading generated bytecode.
>>Any and all tips would be most appreciated.
> I guess a lot depends on why you are creating the class loader.
> The context class loader is specific to the current thread and can be
> short lived. Thus assigning the current thread's context class loader to
> an object that can be shared by multiple threads, or one that may live
> longer than the current thread seems to make no sense.
> Dan.

View raw message