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: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
