Mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Luby <>
Subject Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat
Date Mon, 01 Apr 2002 18:49:55 GMT

Remy Maucherat wrote:

> Fine, but your change creates problems (Jasper does not work on JDK 1.4
> unless you delete common/endorsed/xerces.jar). I don't know why at this
> time, but it should be fixed ASAP.
> (Note: I don't care too much about this functionality ... Adding another CL
> layer is dangerous and makes CL slower; unless other people think this is
> useful I don't think we should add the feature)
> Remy
I think I found the problem. In JDK 1.4, the StandardClassLoader's

loadClass() method appears to be unconditionally delegating to its

parent classloader even when setDelegate is set to false. This
appears to be caused by changes to the URLClassLoader class in JDK

BTW, I can eliminate the use of a separate classloader and put the
jre/lib/ext directory in the existing catalinaLoader and sharedLoader
instances. However, to do this, I need to change the getClassPath()
method in so that it returns a classpath that
is consistent with the classloaders' search order. Right now, the
getClassPath() method (which is used for all JSP compilation) returns
a classpath in the exact opposite order of the order used by the
sharedLoader classloader.

I originally put the extra classloader in to work around this 
getClassPath() bug. However, given the JDK 1.4 differences in the
classloader delegation behavior, I think it would be better for me
to fix the getClassPath() problem and move the jre/lib/ext directory
into the existing catalinaLoader and sharedLoader instances like we
do for the endorsed directories.


Does this sound reasonable to you?



Patrick Luby                     Email:
Sun Microsystems                         Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message