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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
