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) > -Christopher > > (See attached file: sitemap.xmap)(See attached file: index.xsl)(See > attached file: index.xml)(See attached file: error.log) > > > > Christopher Painter-Wakefield wrote: > >>Since we upgraded to Cocoon 2.0.3, we've been experiencing a very > > annoying > >>problem, which is that Cocoon seems to silently handle all exceptions. >>I've tested it now with a couple of exceptions types: RuntimeExceptions >>(thrown by the ESQL logicsheet) and NullPointerExceptions. The behavior > > is > >>that we actually get back a page styled by our stylesheet, but with no >>data. Under C2.0.2, we'd get back a Cocoon error page complete with >>stacktrace. What's going on? > > > Dunno :-/ > > Have you tried outputting the xml of teh xsp and error without other > steps (remove all xslt also in handle-errors and put the xml serializer)? > What do you get? > > >>I looked at the new web.xml init-param "manage-exceptions", but changing > > it > >>to false made things even worse - then I wouldn't even get XSP java > > compile > >>error messages, just a generic internal server error message. > > > manage-exceptions=true should make Cocoon handle the exceptions, while > =false it gives them to the servlet engine. > > >>This problem (I won't say bug, in case it is something we've done!) is > > very > >>detrimental to development, since we have to go look in the logs to find >>out we got an exception. Any help would be appreciated! > > > Please send us the page that is giving you problems, along with the > relevant log snippets, and anything that might help us to understand the > problem. > Thank you. > > -- > Nicola Ken Barozzi [EMAIL PROTECTED] > - 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: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> -- Nicola Ken Barozzi [EMAIL PROTECTED] - 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: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
