You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jay <je...@vmguys.com> on 2003/02/03 21:49:10 UTC

[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  



RE: [PATCH] for 13279

Posted by Jay <je...@vmguys.com>.
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:jevans@vmguys.com]
> > 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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


RE: [PATCH] for 13279

Posted by Hal Deadman <ha...@Tallan.com>.
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:jevans@vmguys.com]
> 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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org