[Classloaders] Establishing the Classloader hierarchy at deployment time

[Jan Bartel <ja...@mortbay.com>]

In tracking down why the temporary Jetty service deployment doesn't run, 
I've noticed a problem with the classloader hierarchy that is 
established at deployment time.

During the deployment of a service, if a service's deployment descriptor 
defines a ClassSpace element, a new classloader is created which 
references only the URLs listed in the element. This classloader is then 
associated with the service instance. This is all good so far. However, 
the service's classloader has no parent set, which results in services 
not being able to find classes in geronimo /lib.

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.

Jan

Re: [Classloaders] Establishing the Classloader hierarchy at deployment time

[Jan Bartel <ja...@mortbay.com>]

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

Re: [Classloaders] Establishing the Classloader hierarchy at deployment time

[Dain Sundstrom <da...@coredevelopers.net>]

On Saturday, September 6, 2003, at 08:26 PM, Jan Bartel wrote:

> In tracking down why the temporary Jetty service deployment doesn't 
> run, I've noticed a problem with the classloader hierarchy that is 
> established at deployment time.

It does run if you use maven run:main, which is the simple startup 
system.  The twiddle startup is currently broken, but jason is planning 
on looking at it when he gets up in a few hours.

> During the deployment of a service, if a service's deployment 
> descriptor defines a ClassSpace element, a new classloader is created 
> which references only the URLs listed in the element. This classloader 
> is then associated with the service instance. This is all good so far. 
> However, the service's classloader has no parent set, which results in 
> services not being able to find classes in geronimo /lib.

It is a problem with the current structure of our system.  Only the 
jars necessary for booting the system should be in lib (and in the 
system class loader).  Another big problem is everything is in a single 
geronimo-core-DEV.jar, which must be on the system class path to boot, 
so everything the non boot time services require also has to be on the 
system class path.  This is why I am working on migrating the bits 
critical at boot-time to the kernel.

> 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.

-dain