You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Garrick Dasbach <ga...@musicrebellion.com> on 2004/10/26 23:12:52 UTC
Re: JspGenerator doesn't work from flow but does otherwise...
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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JspGenerator doesn't work from flow but does otherwise...
Posted by Garrick Dasbach <ga...@musicrebellion.com>.
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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: JspGenerator doesn't work from flow but does otherwise...
Posted by Garrick Dasbach <ga...@musicrebellion.com>.
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: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
Re: JspGenerator doesn't work from flow but does otherwise...
Posted by Joerg Heinicke <jo...@gmx.de>.
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
Re: JspGenerator doesn't work from flow but does otherwise...
Posted by Joerg Heinicke <jo...@gmx.de>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org