MyFaces Core
  1. MyFaces Core
  2. MYFACES-2583

f:ajax cannot retrieve clientId from component

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-beta-2
    • Fix Version/s: 2.0.0-beta-3
    • Component/s: JSR-314
    • Labels:
      None
    • Environment:
      JSF

      Description

      This code:
      <h:form id="myForm">
      <h:inputText value="#

      {myBean.test}">
      <f:ajax render="#{myBean.bindingMyTest.clientId}" event="keyup"/>
      </h:inputText>
      <h:inputText id="myText" value="#{myBean.test}

      " binding="#

      {myBean.bindingMyTest}

      " />
      </h:form>

      produces java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Collection

      while this works:
      <h:form id="myForm">
      <h:inputText value="#

      {myBean.test}">
      <f:ajax render="myForm:myText" event="keyup"/>
      </h:inputText>
      <h:inputText id="myText" value="#{myBean.test}

      "/>
      </h:form>

      On Mojarra both work fine. My guess is here's some problem with the special lifecycle of bindings properties.

      1. MyFaces_Test.war
        2.68 MB
        Ganesh Jung

        Activity

        Hide
        Ganesh Jung added a comment -

        After starting your appserver with this war just call http://localhost:8080/MyFaces_Test/test.faces and you'll get
        java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Collection

        Show
        Ganesh Jung added a comment - After starting your appserver with this war just call http://localhost:8080/MyFaces_Test/test.faces and you'll get java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Collection
        Hide
        Jakob Korherr added a comment -

        I guess the problem is that it was thought that a ValueExpression for the render property of f:ajax has to resolve to a Collection of clientIds. But, of course, it can also resolve to a String.

        So the only thing to do here is check the type of the resolved ValueExpression also for String and handle it separately. I'll do this today, if that's ok for you, Ganesh.

        Show
        Jakob Korherr added a comment - I guess the problem is that it was thought that a ValueExpression for the render property of f:ajax has to resolve to a Collection of clientIds. But, of course, it can also resolve to a String. So the only thing to do here is check the type of the resolved ValueExpression also for String and handle it separately. I'll do this today, if that's ok for you, Ganesh.
        Hide
        Jakob Korherr added a comment -

        After digging into this problem I realized that this seems to be a different problem. The problem is that the ValueExpression (in our case for the attribute render, but in the code also for execute) is evaluated when the component tree is built, which is completely wrong, because this prohibits the real usage of ValueExpressions: changing values!

        In your case, Ganesh, the real problem is that at the time the ValueExpression is evaluated, the component is not yet bound to the property in the managed bean and thus the ValueExpression resolves to null and thus the String is not "parsed" into a Collection at that time. Then, when the render attribute is evaluated, the ValueExpression resolves to the clientId, which is of course a String, but the runtime expects a (pre-processed) Collection. Thus the ClassCastException.

        Show
        Jakob Korherr added a comment - After digging into this problem I realized that this seems to be a different problem. The problem is that the ValueExpression (in our case for the attribute render, but in the code also for execute) is evaluated when the component tree is built, which is completely wrong, because this prohibits the real usage of ValueExpressions: changing values! In your case, Ganesh, the real problem is that at the time the ValueExpression is evaluated, the component is not yet bound to the property in the managed bean and thus the ValueExpression resolves to null and thus the String is not "parsed" into a Collection at that time. Then, when the render attribute is evaluated, the ValueExpression resolves to the clientId, which is of course a String, but the runtime expects a (pre-processed) Collection. Thus the ClassCastException.
        Hide
        Ganesh Jung added a comment -

        This is what I call fast! Thank you, Jakob!

        Show
        Ganesh Jung added a comment - This is what I call fast! Thank you, Jakob!

          People

          • Assignee:
            Jakob Korherr
            Reporter:
            Ganesh Jung
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development