Summary: | Unable to find unambiguous method in class String | ||
---|---|---|---|
Product: | Tomcat 7 | Reporter: | Sebastian <sebastian.ricaldoni> |
Component: | Jasper | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | 7.0.55 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
Attachments: |
Test
Test |
Description
Sebastian
2014-04-17 19:12:41 UTC
In the String class there is no such method as "replace(String, String)" The methods are replace(CharSequence, CharSequence) replace(char, char) Method matching was changed in 7.0.53 (implementing fix for bug 55483). Apparently when searching for a method in Util.findWrapper() there is no distinction between "isAssignableFrom" and "isCoercibleFrom" parameters when weighting potential matches. I do not see any place in EL specification that clarifies how method matching is performed. By the way, for your use case I can suggest to use fn:replace() function from JSTL tag library, http://tomcat.apache.org/taglibs/standard/ Thanks for the report. This has been fixed in 8.0.x for 8.0.6 onwards and in 7.0.x for 7.0.54 onwards. Can I see the commit where this bug was fixed? I ran into this bug when upgrading from 7.0.50 to 7.0.55. I was looking at the latest code for BeanELResolver.java and Util.java. At a glance, it looks like: getWrapper() does a bunch of fancy things including type coercion getMethod() only looks for a perfect match. I don't see BeanELResolver calling getWrapper() anywhere, only getMethod(). This matches the behaviour I'm seeing, where I get MethodNotFoundExceptions forr mappings like: doFoo(Integer bar) -> doFoo(int bar) Hi, This is the revision r1590121. Can you provide a test where you see the issue? Regards, Violeta Created attachment 32137 [details]
Test
The following test reproduces the issue.
Created attachment 32140 [details]
Test
The first problem in the attached test - testBug56425a is:
java.lang.ClassCastException: java.lang.Long cannot be cast to [Ljava.lang.Object;
at org.apache.el.lang.ELSupport.coerceToArray(ELSupport.java:497)
at org.apache.el.lang.ELSupport.coerceToType(ELSupport.java:484)
at org.apache.el.ExpressionFactoryImpl.coerceToType(ExpressionFactoryImpl.java:47)
at javax.el.Util.isCoercibleFrom(Util.java:493)
at javax.el.Util.findWrapper(Util.java:293)
at javax.el.Util.findMethod(Util.java:213)
at javax.el.BeanELResolver.invoke(BeanELResolver.java:157)
at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:84)
at org.apache.el.parser.AstValue.getValue(AstValue.java:157)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:187)
at javax.el.ELProcessor.getValue(ELProcessor.java:61)
at javax.el.ELProcessor.eval(ELProcessor.java:54)
at javax.el.TestUtil.testBug56425a(TestUtil.java:48)
I'm attaching possible fix for this ClassCastException.
The second problem in the test - testBug56425b still failes with:
javax.el.MethodNotFoundException: Unable to find unambiguous method: class javax.el.TesterBean.setValueInt(java.lang.Long)
at javax.el.Util.findWrapper(Util.java:343)
at javax.el.Util.findMethod(Util.java:213)
at javax.el.BeanELResolver.invoke(BeanELResolver.java:157)
at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:84)
at org.apache.el.parser.AstValue.getValue(AstValue.java:157)
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:187)
at javax.el.ELProcessor.getValue(ELProcessor.java:61)
at javax.el.ELProcessor.eval(ELProcessor.java:54)
at javax.el.TestUtil.testBug56425b(TestUtil.java:55)
The array handling fix looks lood to me. I'm looking into the second issue now. The second test case is not valid. Numeric literals are treated as instances of Long (as per the EL spec). There are two matching methods. One with a paremeter of int and one with a parameter of Integer. There is no way for EL to differentiate bewtween them. The match is ambiguous (both matches would require co-ercion). Therefore Tomcat's behaviour here is correct. I'll get the fix for the first issue committed shortly. The additional array issue has been fixed in Tomcat 8.0.x in 8.0.15 onwards. It does not occur in earlier versions. |