geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Bartel <j...@mortbay.com>
Subject Re: [Classloaders] Establishing the Classloader hierarchy at deployment time
Date Sun, 07 Sep 2003 02:39:52 GMT
Dain,

<snip>
>> I have patched, but not yet committed, the ClassSpace constructor to 
>> set a parent for the classloader like so:
>>
>>   public ClassSpace(String name, URL[] urls)
>>   {
>>     super(urls,
>>       Thread.currentThread().getContextClassLoader()!=null?
>>             Thread.currentThread().getContextClassLoader()
>>             :
>>             ClassSpace.class.getClassLoader());
>>      .
>>      .
>>      .
>>     }
>>
>>
>> If anybody has a good reason for this patch not to be committed, then 
>> speak now, or it will go into the codebase today.
> 
> 
> I don't think you don't want to do that.  Class space is a registered 
> JMX class loader, so I believe that it's parent should be the main JMX 
> class loader.  I think this is necessary for JMX 1.2 class loading to 
> work properly.  If you wait a few hours I should have the kernel stuff 
> sorted and Jason should be a wake to take it the last mile.
I am happy not to commit this right now and wait a couple of hours.  I 
am able to make progress with this patch in place for me locally. 
However, I can't see what you're saying about the parent of the 
ClassSpace being the main JMX class loader - the code never sets a 
parent classloader for a new ClassSpace instance at all, let alone 
setting it explicitly to the JMX one.  Surely each classloader needs to 
have it's parent set in order for delegation to work correctly? 
Otherwise, we definitely will wind up with having to have everything on 
the system classpath???!

Jan


Mime
View raw message