I stand corrected. In retrospect, the second patch is a bit of a stretch to tie logging levels to error handling functionality. Perhaps it is best to apply the first patch (or variant thereof) and revisit the tiles (and forwarding?) exception handling in some future version. The first patch will at least allow us to override the current exception-handling behavior.
Since I have yet to post the message on bugzilla, I will edit the text of the original message before posting in light of your comments. Thank you, Jay On Mon, 2003-02-03 at 16:12, Hal Deadman wrote: > The second patch relies on the JSPException class with the root exception, > available in J2EE 1.3 (jsp1.2?). I think Struts may still be supporting J2EE > 1.2 (jsp1.1?). > > http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/servlet/jsp/JspException > .html > > http://java.sun.com/j2ee/sdk_1.2.1/techdocs/api/javax/servlet/jsp/JspExcepti > on.html > > I don't think the fact that debug is enabled should be used to change the > exception handling. Normally log levels can be changed without any impact > other than increased or decreased verbosity. > > Hal > > > -----Original Message----- > > From: Jay [mailto:[EMAIL PROTECTED]] > > Sent: Monday, February 03, 2003 3:49 PM > > To: Struts Development > > Subject: [PATCH] for 13279 > > > > > > Cedric et.al; > > > > Enclosed are two proposed patches for the "swallowing exception" > > behavior of taglib/tiles/InsertTag.java (Bugzilla #13279). The first, > > "InsertTagNoFuncChange.txt", does what I originally suggested: merely > > move the real handling of processException to a method outside of the > > inner class to a protected method in InsertTag where sub-classing and > > overriding the default behavior can easily be done. > > > > The second patch ("InsertTagFuncChange.txt") does change the > > behavior by > > only "swallowing" the exception when the log4j debug level is enabled > > for the class. If debug is not enabled, the exception will be wrapped > > and "re-thrown" as the root cause of a JspException. > > > > I think the second alternative is the better one because a default > > behavior of broadcasting exceptions on the web page is not > > particularly > > desirable. However, I will be happy if either alternative is applied > > > > I have provided complete javadoc comments for both > > alternatives that you > > may change as required. > > > > Thank you, > > Jay > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
