[Classloaders] Establishing the Classloader hierarchy at deployment time

[Jan Bartel]

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