tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Tomcat 3.3 (JDK 1.1 compatibility fixes)
Date Thu, 06 Sep 2001 21:20:20 GMT
Thanks James, I'm very happy to see your contributions. ( and my
appologies for not testing with 1.1 often enough ).

> jakarta-tomcat-3.3-dev-src\src\share\org\apache\tomcat\util\depend\
> ======================================================================
> The method "loadClassInternal" appears to be incorrect.  When loading a
> class, the code first retrieves the class as a resource from the "parent"
> class loader.  But, the return value from the "getResource" is not used
> because the code then delegates the class loading to the "parent2" class
> loader ("parent2.loadClass(name)").  When running with JDK 1.1, the
> "getResource" returns null because the "jar" protocol is not valid (the
> exception message "unknown protocol: jar" is thrown from SimpleClassLoader
> where a is constructed).  This causes the "loadClassInternal"
> method to throw a "ClassNotFoundException" prematurely because the class
> can successfully be loaded by one of the the parent class loaders.  Below I
> offer a solution but I think it would be best if someone with a more
> in-depth understanding of the code can validate this solution.

The code is a bit tricky. 3.3 uses normal URLClassLoaders for loading, but
in order to support reloading we use an additional wrapper (
DependClassLoader ) that will collect dependencies ( since a servlet/jsp
can depend on multiple jars/classes ).

For DCL, "parent" is the webapp class loader. "parent2" is the
applications class loader, parent of all webapp loaders.

The code tries to make DependClassLoader as non-intrusive as possible (
i.e. the behavior of using DCL should be as close as possible to 'normal'

If a class can be loaded by parent2 ( the common app loader ), then we
just delegate to it ( that's the normal delegation that would be used if
no DCL was present ). We don't delegate to parent because then all classes
loaded as result of resolving the current class would not be registered as
depends ( parent will do all the loading without any notification ).

If not, we'll use parent to get the bytes - then load them. The reason we
have DependClassLoader12 is to support the security context - I couldn't
find any other way ( like via jdkcompat ) since we need to call a
protected method in super.

>       // check parent class
>       if( parent != null ) {
>          try {
>             c = parent.loadClass( name );

^^^ That will not brake part of reloading - parent will load all classes
that are requested by the current class, and we'll not be able to record

I'll try to find another fix ( nice try ! :-).


View raw message