I have encountered an issue with the above mentioned file and method. I
was experiencing a problem compiling JSP pages and tracked the issue
down to the setClassPath() method not properly setting up the classpath
for the Jasper Compiler.
Problem:
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: -1 in the jsp file: null
The reason for the problem was that my source was using the
"-Djava.system.class.loder" option and overriding the default System
Class Loader, which is $LauncherAppClassLoader.
I was working with the 4_1_29 version of the Tomcat source, but I have
also had a look at the 5_0_26b version and see the same problem. The
5_0_26b version helps to address, but from my view doesn't solve it. I
am not going to test my solution on it or check to see if it does or
doesn't work for sure, but I will discuss what I think the problem is.
The code in the 5_0_26b version of setClassPath is as follows:
while(loader!=null) {
if(!(loader instanceof URLClassLoader)) {
// do some stuff to see whether or not you can get the classpath
// if you can't then break out of the loop [this is the problem]
}
// turn the file URLs into a classpath string
loader = loader.getParent();
}
In the event that the system is using a customized system class loader
then this code will always fail unless the class loader defines a
"getClassPath()" method. To me this is an unlikely event, although it
is a method for binder ones custom loader with Tomcats needs for the
classpath. If there is an unknown class loader then that doesn't
necessarily mean that Tomcat cannot get the classpath information it
wants from the parent loaders.
By changing the above code to:
while(loader!=null) {
if(!(loader instanceof URLClassLoader)) {
// do some stuff to see whether or not you can get the classpath
// if you can't then don't do anything and let if fall off the if
block
}
else {
// turn the file URLs into a classpath string
}
loader = loader.getParent();
}
I won't be participating any further in this mailing list.
Regards,
Alexander T. Bussmann
Software Engineer
Redknee Inc.
