MyFaces Core
  1. MyFaces Core
  2. MYFACES-3300

Ajax behavior change from 2.1.1 to 2.1.2

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.2
    • Fix Version/s: 2.0.10, 2.1.4
    • Component/s: None
    • Labels:
      None

      Description

      I am currently trying to update some examples to Myfaces 2.1.2 and ran into some ajax related problems. I have a h:selectBooleanCheckbox component that collapses and expands two input fields via f:ajax. There is a value change listener for the checkbox that sets the value internally and calls renderResponse(). In f:ajax, those input fields are also listed in execute to preserve the input the user has potentially made. So far, I had no problems with this solution. The validation for the input fields did not kick in (or did not bother me) and the values were preserved.

      With 2.1.2 I have two issues:
      1) Even if the input values are valid the values in the input fields vanish when they are expanded and collapsed again.
      2) Now validation kicks in for invalid values and I get an error message in the browser

      This works with all older versions I tried (2.0.4, 2.1.0 and 2.1.1).

      Would be interesting to know what really changed here!

        Issue Links

          Activity

          Hide
          Jakob Korherr added a comment -

          fix committed on MYFACES-3301

          Show
          Jakob Korherr added a comment - fix committed on MYFACES-3301
          Hide
          Jakob Korherr added a comment -

          Hi Michi,

          I found the bug. The problem originates from the new ContextAware exception reporting system in MyFaces: In MethodExpressionValidator.validate() the validator gets called in a try {} catch (ELException) {} block, and in the catch block the caught ELException is checked if it was caused by a ValidatorException. In MyFaces 2.1.1 (and before) this was true, b/c it was an ELException which was caused by a ValidatorException. Now, due to the exception reporting system, it is a ContextAwareELException which was caused by an ELException which was caused by a ValidatorException. Thus the check fails and the ValidatorException is not handled as a validation error, but as an ELException, and thus the error.

          Fortunately, in your case there is an easy fix, which I'd recommend anyway: use immediate="true" on the h:selectBooleanCheckbox! This will move the ValueChangeEvent to the end of phase 2 and thus the validator won't even be called and the state will also not be lost, b/c the submitted values have already been applied.

          If you check your example again with MyFaces 2.1.1 (and before), you will see that without immediate="true" on the h:selectBooleanCheckbox you will also see the error there, however not on the browser via javascript alert, but in the server log as unhandled FacesMessage (which was created by the properly handled ValidationException), looking like this:

          WARNUNG: There are some unhandled FacesMessages, this means not every FacesMessage had a chance to be rendered.
          These unhandled FacesMessages are:

          • Kreditkartennummer muss aus 4 Ziffern bestehen.

          Thanks a lot for reporting this! It tells us that the validation via the validator="" attribute is totally broken in MyFaces 2.1.2. This is a dealbreaker for the 2.1.3 release.

          Show
          Jakob Korherr added a comment - Hi Michi, I found the bug. The problem originates from the new ContextAware exception reporting system in MyFaces: In MethodExpressionValidator.validate() the validator gets called in a try {} catch (ELException) {} block, and in the catch block the caught ELException is checked if it was caused by a ValidatorException. In MyFaces 2.1.1 (and before) this was true, b/c it was an ELException which was caused by a ValidatorException. Now, due to the exception reporting system, it is a ContextAwareELException which was caused by an ELException which was caused by a ValidatorException. Thus the check fails and the ValidatorException is not handled as a validation error, but as an ELException, and thus the error. Fortunately, in your case there is an easy fix, which I'd recommend anyway: use immediate="true" on the h:selectBooleanCheckbox! This will move the ValueChangeEvent to the end of phase 2 and thus the validator won't even be called and the state will also not be lost, b/c the submitted values have already been applied. If you check your example again with MyFaces 2.1.1 (and before), you will see that without immediate="true" on the h:selectBooleanCheckbox you will also see the error there, however not on the browser via javascript alert, but in the server log as unhandled FacesMessage (which was created by the properly handled ValidationException), looking like this: WARNUNG: There are some unhandled FacesMessages, this means not every FacesMessage had a chance to be rendered. These unhandled FacesMessages are: Kreditkartennummer muss aus 4 Ziffern bestehen. Thanks a lot for reporting this! It tells us that the validation via the validator="" attribute is totally broken in MyFaces 2.1.2. This is a dealbreaker for the 2.1.3 release.
          Hide
          Jakob Korherr added a comment -

          OK, thanks for the example. I'll take a look at it!

          Show
          Jakob Korherr added a comment - OK, thanks for the example. I'll take a look at it!
          Hide
          Michael Kurz added a comment -

          Hi Jakob,

          I have already checked the release notes and found nothing in this direction. See the attached an example.

          Show
          Michael Kurz added a comment - Hi Jakob, I have already checked the release notes and found nothing in this direction. See the attached an example.
          Hide
          Michael Kurz added a comment -

          Example to show the issue. Can be started with mvn jetty:run. Go to page /editCustomer.xhtml and click use credit card to see the new behavior. If you make some inputs in the credit card fields and collapse and expand it you can see it.

          Show
          Michael Kurz added a comment - Example to show the issue. Can be started with mvn jetty:run. Go to page /editCustomer.xhtml and click use credit card to see the new behavior. If you make some inputs in the credit card fields and collapse and expand it you can see it.
          Hide
          Jakob Korherr added a comment -

          Hi Michi,

          Here are the 2.1.2 release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12316512

          Could you provide an example-war that shows the problem?

          I am wondering if we should stop the 2.1.3 release, b/c of this issue. WDYT?

          Regards,
          Jakob

          Show
          Jakob Korherr added a comment - Hi Michi, Here are the 2.1.2 release notes: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600&version=12316512 Could you provide an example-war that shows the problem? I am wondering if we should stop the 2.1.3 release, b/c of this issue. WDYT? Regards, Jakob

            People

            • Assignee:
              Jakob Korherr
              Reporter:
              Michael Kurz
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development