Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <418A8CBE.8040609@musicrebellion.com>
Date: Thu, 04 Nov 2004 15:10:38 -0500
From: Garrick Dasbach <garrick@musicrebellion.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040514
MIME-Version: 1.0
To: dev@cocoon.apache.org
CC: joerg.heinicke@gmx.de,  users@cocoon.apache.org
Subject: Re: JspGenerator doesn't work from flow but does otherwise...
References: <20040702150114.69634.qmail@web52609.mail.yahoo.com>
 <40E6B354.5050406@gmx.de> <417EBDD4.8030809@musicrebellion.com>
 <417F4DD4.5010402@gmx.de>
In-Reply-To: <417F4DD4.5010402@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>