> > 1. The class loader of the remote interface is an adaptive
> class loader
> > (which has all the classes). It's parent is a sun.misc.Launcher...
> > loader (maybe it should be the thread context class loader?).
>
> This is wrong. Yeah, it should be either a URLClassLoader if
> the app is
> being loaded from the J2EEDeployer, or an MLet classloader
> (=the server
> classloader). Either of these are set as context classloader
> when deploy
> in EmbeddedTomcat service is called.
Unfortunately, the AdaptiveClassLoader does not set the parent for its
super class (and the getParent method is final in ClassLoader).
However, it does delegate to a parent, which is the thread context class
loader. So, in reality, I think it's parent is the URLClassLoader from
the thread context (unless the VM does something with getParent).
> > I don't know how to make the thread context class loader
> know directly
> > about those classes. Any ideas?
>
> Well, the problem is with the ACL's parent. There is an interceptor
> org.jboss.tomcat.ContextClassLoaderInterceptor in the "contrib" module
> which is for this specific purpose. Are you sure this is being used??
Yes. All it does is this (where context is the Tomcat context):
context.getServletLoader().setParentLoader(Thread.currentThread().getCon
textClassLoader());
This (effectively) sets the "parent" of the adaptive class loader (which
is not the same as what is returned by getParent because of what I wrote
above).
