Re: [PATCH] for 13279

Mon, 03 Feb 2003 14:38:01 -0800

I'll patch the Bugzilla page to mention that not everyone does it that way. We're not alone.

And we do mention it here:

http://jakarta.apache.org/struts/using.html#Bugs

-T.

Karr, David wrote:
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]







--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
























					Reply via email to