After reviewing the Jasper and Cocoon sources, I believe the best fix is
for the CompilingClassLoader to extend URLClassLoader. The problem is
that the Jasper system expects a class loader that contains a list of
class paths. This way the Jasper code can reconstitute a full class
path from the class loader passed to it, plus it's own class loader, and
use this class path to compile the JSPs. Any other base class loader,
such as ClassLoader, or SecureClassLoader, provide no means to recreate
any path information, thus no ability for Jasper to recreate the full
classpath for compilation. Also, I think it's important to play by the
components rules. If Jasper, or Tomcat, or whatever component cocoon is
integrating, requires a certain type of class or component in their API
then who are we to decide that they are wrong? I think cocoon should
play by Jasper's rules and have the CompilingClassLoader extend
URLClassLoader, implementing any URL functionallity necessary to allow
Jasper to recreate a full classpath.
Any ideas on how difficult this would be to do? Time frames?
Garrick
Joerg Heinicke wrote:
Forwarding it to dev mailing list.
Does anybody know a solution for the problem described at
http://marc.theaimsgroup.com/?t=108874467000001&r=1&w=4 (or for the
most important things below).
I suggested to either point out the "wrong" cast to the Tomcat
community or to let CompilingClassLoader extend URLClassLoader or to
"restore" a "normal" ClassLoader.
Joerg
On 26.10.2004 23:12, Garrick Dasbach wrote:
Joerg,
I just ran into this same issue. Have you, or anyone else, found any
solution/workaround to this problem, short of no includes in form pages?
Garrick
Joerg Heinicke wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
