You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Christopher Painter-Wakefield <pa...@mc.duke.edu> on 2002/09/03 19:07:48 UTC
Re: C2.0.3 silently ignoring exceptions
Did any of the Cocoon developers read this thread? Should I post it to
cocoon-dev? I want to make sure these bugs get addressed.
Thanks,
Christopher
Christopher Painter-Wakefield wrote:
> Thanks for the reply. I've attached some sample code that exhibits the
> problem, and a sitemap, xconf, and web.xml in case they are relevant.
> Using this code, if you choose the URL /home (e.g.,
> http://localhost:8080/home , assuming the ROOT webapp), the XSP page
> attempts to read a parameter named "msg", then uppercase its value, and
> pass it to the next stage. The obvious bug here is that if no parameter
is
> provided, the value is null, and the attempt to call the toUpperCase()
> method results in a NullPointerException (error.log also attached).
Under
> C2.0.2, this would be reported back to us through the browser along with
a
> stack trace and so forth, which is very important for debugging in
> development. For production, we merely implemented some simple error
> handlers in the sitemap so our users would get a friendly message,
without
> all the gore.
>
> I did try what you suggested. If I use the XML serializer instead of the
> default, it makes no change. However, if I remove the stylesheet
transform
> step, I do get the error page as in C2.0.2. So the question is, why is
the
> behavior different, and is it correct? If so, is there any way to get
back
> to the C2.0.2 behavior for development?
I don't see a handle-errors part in your sitemap.
Thus, since you have told Cocoon to handle them, it should generate an
internal server exception.
Which somehow it doesn't send... hmmm...
> This led me to wonder whether the error handlers are working correctly in
> C2.0.3, and I found even more bizarre behavior here. I put in my
> production error handler, and it did, in fact, pick up the error and
> display more or less the correct error page.
Ok, good.
> However, it somehow *also*
> ran the index.xsl on the stream. I'm not sure exactly what went on
inside
> Cocoon, but what displayed in my browser had my production error page on
> top, and the styled output from index.xsl right below it. Looking at the
> source, I saw our entire production error page html, followed by the
entire
> html as seen without an error handler, e.g.
>
> <html>
> <body> .... our production error page ...
> </body>
> </html>
> <html>
> <body> ... output from index.xsl ...
> </html>
>
> Which isn't even correct HTML, I think, but IE displayed it anyway.
>
> This is certainly not correct behavior! So, I think I feel safe calling
it
> a bug now. It seems that somehow C2.0.3 is applying the transform
stage(s)
> in the original <map:match> block regardless of whether an error occurs
or
> is handled.
This is /another/ bug I guess :-/
The former has to do with the CocoonServlet error handling, the latter
about how the TreeProcessor handles errors probably.
BTW, are you using the compiled sitemap or the interpreted TreeProcessor
one?
BTW, does the same error happen in 2.1?
(ATM I don't have time to test it, just looked at the files)
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: C2.0.3 silently ignoring exceptions
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Christopher Painter-Wakefield wrote:
> Did any of the Cocoon developers read this thread? Should I post it to
> cocoon-dev? I want to make sure these bugs get addressed.
I am a Cocoon dev (I also wrote the error handling code, but it's not a
compliment ATM I guess), but I have limited time ATM to check it out.
The problem with this error stuff is that it encompasses all Cocoon.
If someone somewhere fails to catch or rethrow the error properly, all
sort of things can happen, mostly stacktraces that are not useful.
The error is most probably as you say: " It seems that somehow C2.0.3 is
applying the transform stage(s) in the original <map:match> block
regardless of whether an error occurs or is handled."
It seems like a TreeProcessor issue, but I'm not sure.
I tried making it appear in 2.1 but instead I get a general Cocoon Error.
Please try it in 2.1, file a bug report on bugzilla, it will be looked
at ASAP.
>
>
> Christopher Painter-Wakefield wrote:
>
>
>>Thanks for the reply. I've attached some sample code that exhibits the
>>problem, and a sitemap, xconf, and web.xml in case they are relevant.
>>Using this code, if you choose the URL /home (e.g.,
>>http://localhost:8080/home , assuming the ROOT webapp), the XSP page
>>attempts to read a parameter named "msg", then uppercase its value, and
>>pass it to the next stage. The obvious bug here is that if no parameter
>
> is
>
>>provided, the value is null, and the attempt to call the toUpperCase()
>>method results in a NullPointerException (error.log also attached).
>
> Under
>
>>C2.0.2, this would be reported back to us through the browser along with
>
> a
>
>>stack trace and so forth, which is very important for debugging in
>>development. For production, we merely implemented some simple error
>>handlers in the sitemap so our users would get a friendly message,
>
> without
>
>>all the gore.
>>
>>I did try what you suggested. If I use the XML serializer instead of the
>>default, it makes no change. However, if I remove the stylesheet
>
> transform
>
>>step, I do get the error page as in C2.0.2. So the question is, why is
>
> the
>
>>behavior different, and is it correct? If so, is there any way to get
>
> back
>
>>to the C2.0.2 behavior for development?
>
>
> I don't see a handle-errors part in your sitemap.
> Thus, since you have told Cocoon to handle them, it should generate an
> internal server exception.
> Which somehow it doesn't send... hmmm...
>
>
>>This led me to wonder whether the error handlers are working correctly in
>>C2.0.3, and I found even more bizarre behavior here. I put in my
>>production error handler, and it did, in fact, pick up the error and
>>display more or less the correct error page.
>
>
> Ok, good.
>
>
>>However, it somehow *also*
>>ran the index.xsl on the stream. I'm not sure exactly what went on
>
> inside
>
>>Cocoon, but what displayed in my browser had my production error page on
>>top, and the styled output from index.xsl right below it. Looking at the
>>source, I saw our entire production error page html, followed by the
>
> entire
>
>>html as seen without an error handler, e.g.
>>
>><html>
>> <body> .... our production error page ...
>> </body>
>></html>
>><html>
>> <body> ... output from index.xsl ...
>></html>
>>
>>Which isn't even correct HTML, I think, but IE displayed it anyway.
>>
>>This is certainly not correct behavior! So, I think I feel safe calling
>
> it
>
>>a bug now. It seems that somehow C2.0.3 is applying the transform
>
> stage(s)
>
>>in the original <map:match> block regardless of whether an error occurs
>
> or
>
>>is handled.
>
>
> This is /another/ bug I guess :-/
>
> The former has to do with the CocoonServlet error handling, the latter
> about how the TreeProcessor handles errors probably.
>
> BTW, are you using the compiled sitemap or the interpreted TreeProcessor
> one?
>
> BTW, does the same error happen in 2.1?
>
> (ATM I don't have time to test it, just looked at the files)
>
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>