On 02.07.2004 17:01, Terry Brick wrote:
>>> Weird problem. I have a small test JSP that I'm accessing using
>>> JspGenerator. It works fine if I hit it straight from the
>>> browser (with a URL that matches pipeline in my sitemap) but it
>>> fails if I call the exact same thing from my flow script using
>>> sendPage("hello.jsp").<snipped what="most simple use case, calling hello.jsp via cocoon.sendPage()"/>
-------------------------------------------------
URL That Works ------------------------------------------------- http://localhost:8080/Cocoon/jsptest/hello.jsp
-------------------------------------------------
URL That Doesn't Work
------------------------------------------------- http://localhost:8080/Cocoon/jsptest/jspflow
Here's the Exception Stack Trace
Original Exception: java.lang.ClassCastException
at org.apache.jasper.compiler.JspRuntimeContext.<init>(JspRuntimeContext.java:153)
at org.apache.jasper.servlet.JspServlet.init(JspServlet.java:132)
at org.apache.cocoon.components.jsp.JSPEngineImpl.executeJSP(JSPEngineImpl.java:71)
I did remote debugging to find out what caused the ClassCastException. After I have found the correct Tomcat sources - what a hell - I found the reason:
http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspRuntimeContext.java?annotate=1.4.2.5&only_with_tag=TOMCAT_4_1_24#151
The code does: Thread.currentThread().getContextClassLoader() and tries to cast it to URLClassLoader. While it does not fail for "hello.jsp" (classloader is of type WebappClassLoader) it fails for "jspflow" (classloader is of type CompilingClassLoader).
What do you suggest for fixing it? Is it possible to let our CompilingClassLoader extend URLClassLoader? Or shall we hint to Tomcat community that there are also other classloaders? Shall the JSPEngine restore a "normal" classloader?
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
