classloader documentation misrepresents the way it actually works

[vl...@trilogy.com]

Hi:
        I have just finished debugging a complex problem in running some 
GLUE testcases in tomcat 4.1.12 that rely on a custom test framework 
providing an automated way to run tomcat in-proc. The problem is rooted in 
the fact that contrary to the docs WebappClassLoader *will* delegate to 
the system classloader before checking for the value of "delegate" flag, 
as shown by this snippet taken from WebappClassLoader.loadClass():


        // (0.2) Try loading the class with the system class loader, to 
prevent
        //       the webapp from overriding J2SE classes
        try {
            clazz = system.loadClass(name);
            if (clazz != null) {
                if (resolve)
                    resolveClass(clazz);
                return (clazz);
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }

this will load any non-system class present in -classpath *before* step 
(1):

        // (1) Delegate to our parent if requested
        if (delegateLoad) {
        ...


In my case this is causing major problems because I have client-side 
testcases that need GLUE classes in the system classpath to work. When 
GLUE instantiates my services inside my webapp that was created in-proc, 
GLUE classes get delegated to the app classloader even though they are 
deployed via a jar in WEB-INF/lib.

I am aware of the reasons for doing step (0.2). However, a better way to 
guard against webapp attempting to override system classes would have been 
to

- do system.loadClass()
- if that worked, check that the defining classloader of the returned 
class is the primordial loader (getClassLoader() == null) or the extension 
loader [i.e, parent of the system loader]. If that is the case, return the 
class. If not, fall through to allow the parent or webapp loader a chance 
to redefine the same class.

This will perform the desired guard step but only filter our "true" system 
classes, i.e. the ones in rt.jar and extensions.

Thanks,
Vlad.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>