Created attachment 29786 [details] Test case for "Set" It uses "Class.cast" to convert an object to a given class in the code generated by tagPlugin "Set". It causes an exception when the value is primitive type, Here is a sample, Caused by: java.lang.ClassCastException: Cannot cast class java.lang.Integer to int at java.lang.Class.cast(Class.java:1711) at org.apache.jsp.WEB_002dINF.views.error_jsp._jspService(error_jsp.java:108) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) at javax.servlet.http.HttpServlet.service(HttpServlet.java:668) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432) ... 52 more The correct way is to use "ELSupport.coerceToType". Attached a patch and test case for this issue.
Created attachment 29787 [details] Patch for Set.java
Is it appropriate to perform a "coerce" instead of a simple cast? (I don't know whether the spec covers this case). If the only problem is primitive types, I think this can be solved without the complexity of formal coercion.
Yes. The problem isn't only from primitive types. Perform a "coerce" is a better choice. (In reply to comment #2) > Is it appropriate to perform a "coerce" instead of a simple cast? (I don't > know whether the spec covers this case). If the only problem is primitive > types, I think this can be solved without the complexity of formal coercion.
It is not a question of what is appropriate or what is best, the JSTL specification requires that an EL coerce is used. I'm looking at this now. The test case is going to need some work.
Many thanks for the patch. It has been applied to trunk and 7.0.x and will be included in 7.0.35 onwards. I added a different test case to trunk that tests that the coercion works rather than tests the source code for a particular string. Note that the trunk tests for the tag plug-ins depend on the new resources implementation so they have not been back-ported to 7.0.x.