el-spec
  1. el-spec
  2. EL_SPEC-11

Clarify how single variable evaluates to method

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Labels:
      None

      Description

      Section 1.2.1.2 in the EL specification mentions that a method expression can consist of a single variable:

       
      A method expression shares the same syntax as an lvalue. 
      That is, it can only consist of either a single variable
      (e.g. ${name}) or a property resolution on some object, 
      via the . or [] operator (e.g. ${employee.name}).

      As it appears, it's not entirely clear how such single variable should be evaluated.

      In the reference implementation for example, we see that in this case a MethodExpressionImpl will reference an AstIdentifier, which will use the context's variable mapper to obtain a ValueExpression. The value is then obtained from this value expression, and it's expected to be a MethodExpression, which is then invoked.

      This can be seen at http://java.net/projects/el-spec/sources/source-code/content/trunk/impl/src/main/java/com/sun/el/parser/AstIdentifier.java?rev=198 where the method getMethodExpression at line 198 demonstrates the "value expression wrapping a method expression" assumption. invoke at line 183 then shows this obtained method expression is simply invoked.

      Comments on line 198 and 209 explicitly mention 2 cases:

      case A: ValueExpression exists, getValue which must
      be a MethodExpression

      [...]

      case B: evaluate the identity against the ELResolver, again, must be
      a MethodExpression to be able to invoke

      These cases however are not outlined in the specification. As a result, alternative EL implementations (like JUEL) have taken a completely different approach. In the case of JUEL, it also expects a ValueExpression, but then guessed that this value expression should be wrapping a Method. This on its turn leads to unexpected behavior and bugs such as reported here: http://code.google.com/p/omnifaces/issues/detail?id=100

      In order to ensure portability between EL implementations, I would like to request this specific case to be clarified in the specification.

        Activity

        arjan tijms created issue -
        Hide
        beckchr added a comment - - edited

        See also this issue from 2006: http://java.net/jira/browse/JSP_SPEC_PUBLIC-164

        Show
        beckchr added a comment - - edited See also this issue from 2006: http://java.net/jira/browse/JSP_SPEC_PUBLIC-164
        Hide
        kchung added a comment -

        What about adding the following clarification to 1.2.1.2

        When a MethodExpression created from an EL expression of the form $

        {name}

        is invoked,

        1. The identifier "name" is first evaluated.
        a. If "name" is an EL variable, the ValueExpression associated with the variable is evaluated.
        b. Else obtain the value resolved in the ELResolvers.
        2. If the identifier evaluates to a MethodExpression, it is invoked and its result is returned.
        3. Else error.

        Show
        kchung added a comment - What about adding the following clarification to 1.2.1.2 When a MethodExpression created from an EL expression of the form $ {name} is invoked, 1. The identifier "name" is first evaluated. a. If "name" is an EL variable, the ValueExpression associated with the variable is evaluated. b. Else obtain the value resolved in the ELResolvers. 2. If the identifier evaluates to a MethodExpression, it is invoked and its result is returned. 3. Else error.
        Hide
        kchung added a comment -

        Added a new section 1.5.4. in EL 3.0 spec to clarify the issue.

        Show
        kchung added a comment - Added a new section 1.5.4. in EL 3.0 spec to clarify the issue.
        kchung made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        arjan tijms added a comment -

        What about adding the following clarification to 1.2.1.2 [...]

        It sounds okay to me, thanks!

        Show
        arjan tijms added a comment - What about adding the following clarification to 1.2.1.2 [...] It sounds okay to me, thanks!

          People

          • Assignee:
            Unassigned
            Reporter:
            arjan tijms
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: