Re: C2.0.3 silently ignoring exceptions
Sorry, I didn't realize you were one of the developers. I'll file a bug report at least, and see what I can do about checking out 2.1, but I don't have much time for this, either. Whatever changed, changed between 2.0.2 and 2.0.3, which ought to help highlight the problem code. -Christopher 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 [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]
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: C2.0.3 silently ignoring exceptions
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 [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]
Re: C2.0.3 silently ignoring exceptions
snip BTW, are you using the compiled sitemap or the interpreted TreeProcessor one? The interpreted one. BTW, does the same error happen in 2.1? I don't know; we've been working solely with the released code. snip -Christopher - 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]
Re: C2.0.3 silently ignoring exceptions
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]
Re: C2.0.3 silently ignoring exceptions
I agree users shouldn't see the stacktrace, but neither should they get a page that looks basically right but with no data, no errors, and no explanation that a problem has occurred - this might be even worse, as it might lead them to believe something (there is no data matching their search, for instance) that isn't true. The stacktrace is easy to avoid by implementing error handler stylesheets and installing them in your production sitemap, which is what we are doing. The user gets a friendly error message that exposes nothing internal, but lets them know something is wrong. -Christopher On Wednesday, August 28, 2002, at 05:57 , Christopher Painter-Wakefield wrote: 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! Although this is indeed annoying when developing, I would tend to view this a A Good Thing(tm) for a production server, as exposing a stacktrace to anyone who gets the error is kinda, err... personal. It seems to me -- I could be wrong on this -- that the more internal information disclosed, the more vulnerable one could be. I'm still using 2.0.2 so I haven't seen this. A. - 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]
Re: C2.0.3 silently ignoring exceptions
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]
Re: C2.0.3 silently ignoring exceptions
did anyone get the mail with the attachments? I had to resend it with fewer attachments because it was rejected as too large the first time. The second time it seemed to go through (I received it from cocoon-users), but I got a different message complaining about the size, plus a separate message saying it was blocked for some reason (like it had a virus, but no virus name was given, and the problem was supposedly in my attached stylesheet). Argh! If nobody received it, I'll send it yet again and send code snippets in the body of the text rather than attachments. -Christopher - 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]
RE: C2.0.3 silently ignoring exceptions
Title: RE: C2.0.3 silently ignoring exceptions I got it. -Original Message- From: Christopher Painter-Wakefield [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 12:14 PM To: [EMAIL PROTECTED] Subject: Re: C2.0.3 silently ignoring exceptions did anyone get the mail with the attachments? I had to resend it with fewer attachments because it was rejected as too large the first time. The second time it seemed to go through (I received it from cocoon-users), but I got a different message complaining about the size, plus a separate message saying it was blocked for some reason (like it had a virus, but no virus name was given, and the problem was supposedly in my attached stylesheet). Argh! If nobody received it, I'll send it yet again and send code snippets in the body of the text rather than attachments. -Christopher - 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]
RE: C2.0.3 silently ignoring exceptions
thank you. I got it. -Original Message- From: Christopher Painter-Wakefield [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 12:14 PM To: [EMAIL PROTECTED] Subject: Re: C2.0.3 silently ignoring exceptions did anyone get the mail with the attachments? I had to resend it with fewer attachments because it was rejected as too large the first time. The second time it seemed to go through (I received it from cocoon-users), but I got a different message complaining about the size, plus a separate message saying it was blocked for some reason (like it had a virus, but no virus name was given, and the problem was supposedly in my attached stylesheet). Argh! If nobody received it, I'll send it yet again and send code snippets in the body of the text rather than attachments. -Christopher - 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] - 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]
Re: C2.0.3 silently ignoring exceptions
On Wednesday, August 28, 2002, at 05:57 , Christopher Painter-Wakefield wrote: 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! Although this is indeed annoying when developing, I would tend to view this a A Good Thing(tm) for a production server, as exposing a stacktrace to anyone who gets the error is kinda, err... personal. It seems to me -- I could be wrong on this -- that the more internal information disclosed, the more vulnerable one could be. I'm still using 2.0.2 so I haven't seen this. A. - 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]
