aggh! The listserv host rejected my mail as too large. Okay, I'll try it again without the xconf and web.xml. If these seem relevant, I'll send them separately.
----- Forwarded by Christopher Painter-Wakefield/mcis/mc/Duke on 08/29/2002 03:06 PM ----- 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? 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. 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. -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) --------------------------------------------------------------------
sitemap.xmap
Description: Binary data
index.xsl
Description: Binary data
index.xml
Description: Binary data
error.log
Description: Binary data
--------------------------------------------------------------------- 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]>
