Author: kkolinko Date: Sun Jan 31 04:10:41 2010 New Revision: 904977 URL: http://svn.apache.org/viewvc?rev=904977&view=rev Log: votes
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=904977&r1=904976&r2=904977&view=diff ============================================================================== --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Sun Jan 31 04:10:41 2010 @@ -135,14 +135,20 @@ * Add some debug logging where exceptions where previously swallowed http://svn.apache.org/viewvc?rev=904834&view=rev - +1: mark + +1: markt, kkolinko + -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48629 Get nested role search working when {1} is used in roleSearch Patch provided by Gabriel http://svn.apache.org/viewvc?rev=904914&view=rev +1: markt - -1: + -1: + -0: kkolinko: I think using groupDN for {1} does not match the + documentation, and I am not sure that it will work even for the OP of that issue, + though I would like to know more about his configuration to be sure. + See my comment #2 for that issue. + * Fix various EL TCK failures http://svn.apache.org/viewvc?view=rev&rev=899653 (signatures) @@ -157,6 +163,47 @@ http://svn.apache.org/viewvc?view=rev&rev=899935 (ELException expected) http://svn.apache.org/viewvc?view=rev&rev=899949 (ignore whitespace on comp) +1: markt + +1: kkolinko: + 899653: OK. We do not have @Deprecated annotations in those classes, + so the patch is about adding @SuppressWarnings("dep-ann") + 899769: With 899770 that backports the message string used here. + 899770: OK + (Maybe better name for that message, because it says about arrays, + yet name is rather generic). + 899783: OK + 899788: OK + (Likewise, o.a.jasper.el.ELResolverImpl#getType(ELContext,Object,Object) + should probably throw a PropertyNotFoundException, instead of returning null. + I have no proof, though.) + 899792: OK + 899916: OK + + 899918, 899919: OK, but there is probably an omission in the EL spec: + I do not see why we do conversion Enum->Enum via toString() call. + + The EL spec chapter 1.18.6 'Coerce A to an Enum Type T' says + "If A is a String call Enum.valueOf(T.getClass(), A) and return the result." + It does not say what to do if A is not a String. (There is no + explicit "Otherwise, error" statement below). + + In 1.18.7 (aka ELSupport#coerceToType(Object, Class)) we throw + an error if A is not a String. Even if T has a PropertyEditor, + we do not do editor.setAsText(obj.toString()), as the spec does + not say to do so, but throw an exception. + + (In 1.18.7 the spec says "Otherwise, apply T's PropertyEditor", + but PropertyEditor can be applied only is A is a String. Am I right?) + + Without 899919 patch we will throw a ClassCaseException when object type + is a different type of enum, but other values are still converted + via toString() call. The patch makes that behaviour consistent, even + if I do not understand why it is allowed. + + 899935: OK + 899949: OK, + but why ValueExpressionImpl.equals() is implemented as comparing + the hash codes? What will happen with false positives? + -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48627 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org