His comment about the web page statement is valid, however. Is it an apache-wide policy to only use patches attached in bugzilla (despite what the page says), or is it inconsistent? If we (Struts) are varying from the convention, then perhaps we should have a little statement on the Struts page that mentions our variance from the convention.
-----Original Message----- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, February 03, 2003 1:20 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] for 13279 I know that's what it says but we don't follow that convention. I personally never save any patches that come through the mail. I *only* consider patches attached to a bugzilla ticket. David >From: Jay <[EMAIL PROTECTED]> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> >To: Struts Developers List <[EMAIL PROTECTED]> >Subject: Re: [PATCH] for 13279 >Date: 03 Feb 2003 16:17:07 -0500 > >David: > >Thanks, I will do so. But you should know that I simply followed the >instructions posted on the bug database home page >(http://jakarta.apache.org/site/bugs.html): > >"If you have a patch to submit, please mail it to the appropriate >developer mailing list. Use the prefix "[PATCH]" on your message >subject. Please include any relevant bug numbers . ." > >Does this page need updating given your practice and perhaps the >practice of other Apache projects? > >Jay > > > >On Mon, 2003-02-03 at 15:50, David Graham wrote: > > Please post this to the bugzilla ticket. We don't accept patches >through > > the mailing list because they tend to get lost. > > > > David > > > > > > > > >From: Jay <[EMAIL PROTECTED]> > > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]> > > >To: Struts Development <[EMAIL PROTECTED]> > > >Subject: [PATCH] for 13279 > > >Date: 03 Feb 2003 15:49:10 -0500 > > > > > >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 > > > > > > > > ><< InsertTagNoFuncChange.txt >> > > ><< InsertTagFuncChange.txt >> > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > _________________________________________________________________ > > The new MSN 8: advanced junk mail protection and 2 months FREE* > > http://join.msn.com/?page=features/junkmail > > > > > > --------------------------------------------------------------------- > > 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] _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 --------------------------------------------------------------------- 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]
