You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2010/02/14 13:07:27 UTC

svn commit: r910001 - /tomcat/tc6.0.x/trunk/STATUS.txt

Author: markt
Date: Sun Feb 14 12:07:27 2010
New Revision: 910001

URL: http://svn.apache.org/viewvc?rev=910001&view=rev
Log:
Fix copy/paste error in proposal

Modified:
    tomcat/tc6.0.x/trunk/STATUS.txt

Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=910001&r1=910000&r2=910001&view=diff
==============================================================================
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Sun Feb 14 12:07:27 2010
@@ -183,14 +183,10 @@
   fragment helper has been used for the parent tag (if any). Where such a helper
   has been used, the variables must be redefined.
   Test cases for both bugs and the JSP TCK pass with this patch applied.
-  http://people.apache.org/~markt/patches/2010-02-02-bug42390.patch
+  http://people.apache.org/~markt/patches/2010-02-14-bug42390.patch
   +1: markt
   -1: kkolinko:
-    1. There is a copy-paste issue in the patch:
-       vec.add(tagVarInfos[i]); call was replaced by vec.add(varInfos[i]);
-       which is wrong. This error is not present in trunk.
-
-    2. isImplemetedAsFragment() method is wrong.
+    1. isImplemetedAsFragment() method is wrong.
        1) A fragment can also be created with <jsp:attribute> when calling a tag,
          when the attribute is declared being of type JspFragment.
          -see JSP.5.10 <jsp:attribute>, or the places where the following method is called:
@@ -199,10 +195,10 @@
        2) It should navigate up the parents chain. The SimpleTag can be one
          of our parents, not necessary the immediate one.
 
-    3. I think that BZ 48616 cannot/should not be fixed - see Comment 15 to
+    2. I think that BZ 48616 cannot/should not be fixed - see Comment 15 to
       the issue.
 
-    4. Should we fix BZ 42390 in TC 5.5, and bring on BZ 48616 there, if it
+    3. Should we fix BZ 42390 in TC 5.5, and bring on BZ 48616 there, if it
     was historically working? I have doubts.
 
     Reviewing this as a whole, I have questions regarding the following field:



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