|Summary:||javax.el.MapELResolver getType returns class of kept object instead of Object.class|
|Product:||Tomcat 6||Reporter:||Fyodor Kravchenko <fedd>|
|Component:||Servlet & JSP API||Assignee:||Tomcat Developers Mailing List <dev>|
|Attachments:||JSP script reproduces the bug. Uncomment lines 46, 47 to see the real problem.|
Description Fyodor Kravchenko 2011-05-09 11:18:04 UTC
Created attachment 26977 [details] JSP script reproduces the bug. Uncomment lines 46, 47 to see the real problem. Hello, This is observed in Tomcat 6.0.26, Java 1.6 (Netbeans 6.9.1 bundle). The MapELResolver getType method returns the class of the kept object instead of Object.class. The Java specification says, "If the base object is a map, [getType] returns the most general acceptable type for a value in this map", which should mostly be Object.class. This makes impossible, for example, 1) to set a String value to a map expression, if previously that key was mapped to an Integer; 2) if we are putting an Integer to the value which is currently the String, the Integer gets coerced to the String (according to org.apache.el.parser.AstValue implementation, see lines 153-157.) The attached JSP script reproduces this bug. I couldn't figure out whether it is connected with bug 44637 (seems that request was reverse to mine). Thanks!
Comment 1 Mark Thomas 2011-05-09 15:51:42 UTC
Thanks for the test case. I am looking at this now. As an aside, the test JSP is invalid. You can't use hm.int since int is not a valid Java identifier (it is a reserved word). Tomcat 6 lets you get away with this. Tomcat 7 doesn't (unless you explicitly disable the check). This doesn't affect the validity of this bug report. Replacing "int" with "integer" allows the JSP to execute.
Comment 2 Mark Thomas 2011-05-09 16:32:40 UTC
Fixed in 7.0.x for 7.0.14 onwards. Proposed for 6.0.x.
Comment 3 Konstantin Kolinko 2011-05-09 18:35:53 UTC
ListELResolver.getType() has the same issue
Comment 4 Mark Thomas 2011-05-09 18:44:50 UTC
Also fixed in 7.0.x for 7.0.14 and proposed for 6.0.x
Comment 5 Mark Thomas 2011-05-10 08:43:21 UTC
Fixed in 6.0.x and will be included in 6.0.33 onwards.
Comment 6 Fyodor Kravchenko 2011-05-15 07:51:46 UTC
Thanks (if it's appropriate to thank here)!