geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [Classloaders] Establishing the Classloader hierarchy at deployment time
Date Sun, 07 Sep 2003 02:00:08 GMT
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.


View raw message