[jboss-jira] [JBoss JIRA] (WFLY-12947) EL should coerce String to Integer in equals operation

[Ricardo Martin Camarero (Jira)]

     [ https://issues.redhat.com/browse/WFLY-12947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ricardo Martin Camarero moved JBEAP-18439 to WFLY-12947:
--------------------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-12947  (was: JBEAP-18439)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: EE
                           (was: EE)
    Affects Version/s: 18.0.1.Final
                           (was: 7.2.5.GA)
     QE Test Coverage:   (was: +)


> EL should coerce String to Integer in equals operation
> ------------------------------------------------------
>
>                 Key: WFLY-12947
>                 URL: https://issues.redhat.com/browse/WFLY-12947
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 18.0.1.Final
>            Reporter: Ricardo Martin Camarero
>            Assignee: Ricardo Martin Camarero
>            Priority: Major
>
> EAP 7's EL equals operations work differently from EAP 6 one.
> For example: put the following JSP in your web application (e.g. example.war)
> {code:java|title=test.jsp}
> <% request.setAttribute("testAttr", "01"); %>
> ${testAttr == 1}</br>
> ${param['foo'] == 1}<br>
> ${1 == param['foo']}<br>
> ${1 == (0+param['foo'])}<br>
> {code}
> Then, access the above JSP with curl command:
> {code}
> $ curl http://localhost:8080/example/test.jsp?foo=01
> {code}
>  - Expected result (EAP 6's behavior):
> {code}
> true<br>
> true<br>
> true<br>
> true<br>
> {code}
>  - Actual result (EAP 7's behavior):
> {code}
> false<br>
> false<br>
> false<br>
> true<br>
> {code}
> In the section 1.9.2 of [EL 3.0 Specification|https://download.oracle.com/otndocs/jcp/el-3_0-fr-eval-spec/index.html], the ==,!= operators have the following step:
> {code}
> ■If A==B, apply operator
> ■ If A is null or B is null return false for == or eq, true for != or ne.
> ■ If A or B is BigDecimal, coerce both A and B to BigDecimal and then:
> ■ If operator is == or eq, return A.equals(B)
> ■ If operator is != or ne, return !A.equals(B)
> ■ If A or B is Float or Double coerce both A and B to Double, apply operator
> ■ If A or B is BigInteger, coerce both A and B to BigInteger and then:
> ■ If operator is == or eq, return A.equals(B)
> ■ If operator is != or ne, return !A.equals(B)
> ■ If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to Long, apply operator
> ■ If A or B is Boolean coerce both A and B to Boolean, apply operator
> ■ If A or B is an enum, coerce both A and B to enum, apply operator
> ■ If A or B is String coerce both A and B to String, compare lexically
> ■ Otherwise if an error occurs while calling A.equals(B), error
> ■ Otherwise, apply operator to result of A.equals(B)
> {code}
> Note that the step "If A or B is Byte, Short, Character, Integer, or Long coerce both A and B to Long, apply operator" should happen earlier than the step coercion to String. So, it appears that EAP 7's behavior violates the spec.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)