MyFaces Core
  1. MyFaces Core
  2. MYFACES-2528

BeanValidator validation groups are overwritten with PSS

    Details

    • Type: Bug Bug
    • Status: Patch Available
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0-beta
    • Fix Version/s: None
    • Component/s: JSR-314
    • Labels:
      None

      Description

      Setting the validation groups of a bean validator like <f:validateBean validationGroups="#

      {bean.groups}"/> is not always working correctly with PSS. Property bean.groups returns null or the class name of a validation group in my example based on the value of a boolean checkbox:

      <h:selectBooleanCheckbox value="#{bean.prop1}"
      valueChangeListener="#{bean.prop1Changed}"
      immediate="true" onclick="this.form.submit()"/>
      <h:inputText value="#{bean.prop2}" rendered="#{bean.prop1}">
      <f:validateBean validationGroups="#{bean.groups}

      "/>
      </h:inputText>

      If I check the boolean checkbox the form is submitted and rendered again with the additional input field. The problem now is that the validation groups are set correctly on building the view during the second traversal of the lifecycle before restoring the state. But on restoring the validator this value is overwritten with the old value from the state and my validation group is gone again.

      As the BeanValidator is a PartialStateHolder this can be avoided by only saving and restoring the state if the initial state was not marked.

      1. MYFACES-2528.patch
        1.0 kB
        Michael Kurz

        Activity

        Hide
        Jakob Korherr added a comment -

        Thanks Michael. I am very curious about their solution!

        Show
        Jakob Korherr added a comment - Thanks Michael. I am very curious about their solution!
        Hide
        Michael Kurz added a comment -

        Filed issue 1543 on Mojarra for this:

        https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1543

        I think Ed is already aware of the overall problem as he commented on issue 1500 (disabled attribute):

        https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1500

        Show
        Michael Kurz added a comment - Filed issue 1543 on Mojarra for this: https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1543 I think Ed is already aware of the overall problem as he commented on issue 1500 (disabled attribute): https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1500
        Hide
        Jakob Korherr added a comment -

        Hi Michael,

        There are some problems with the validator attributes and ValueExpressions. Not only the validationGroups, but also the disabled attribute. The problem here (on my opinion) is the spec. The way the spec describes these attributes does not (really) allow changing the value of them via a ValueExpression.

        For example the disabled attribute: If this is set to true the validator is not added to the component and its validatorId is added to an exclusion list. So there is no connection to the real validator (or the handler) anymore and a change of the attribute value is just not recognized correctly. The same applies for the validationGroups.

        Maybe you could get in touch with Ed or someone from the EG to get some answers if this is expected or (and that is what i think) just not thought of.

        Thanks!

        Show
        Jakob Korherr added a comment - Hi Michael, There are some problems with the validator attributes and ValueExpressions. Not only the validationGroups, but also the disabled attribute. The problem here (on my opinion) is the spec. The way the spec describes these attributes does not (really) allow changing the value of them via a ValueExpression. For example the disabled attribute: If this is set to true the validator is not added to the component and its validatorId is added to an exclusion list. So there is no connection to the real validator (or the handler) anymore and a change of the attribute value is just not recognized correctly. The same applies for the validationGroups. Maybe you could get in touch with Ed or someone from the EG to get some answers if this is expected or (and that is what i think) just not thought of. Thanks!
        Hide
        Michael Kurz added a comment -

        The patch is anyway not the complete solution as I found out later.

        Show
        Michael Kurz added a comment - The patch is anyway not the complete solution as I found out later.
        Hide
        Leonardo Uribe added a comment -

        I think the patch miss one call to clearInitialState on setValidationGroups. In this way if validationGroups is changed after build view, it state is saved/restored.

        Jakob did/is doing some work on this field, maybe he can answer better than me if this is the way to go.

        Show
        Leonardo Uribe added a comment - I think the patch miss one call to clearInitialState on setValidationGroups. In this way if validationGroups is changed after build view, it state is saved/restored. Jakob did/is doing some work on this field, maybe he can answer better than me if this is the way to go.
        Hide
        Michael Kurz added a comment -

        Out of curiosity I hacked a quick solution for this one that seems to work as I expect it. I simply wrote a tag handler for f:validateBean that checks if the attribute is a value expression. In that case this expression is directly set on the BeanValidator (new property validationGroupsExpression). BeanValidator evaluates this expression if it is set.

        Though this works for me with partial and full state saving I don't know if it is the way to go.

        Show
        Michael Kurz added a comment - Out of curiosity I hacked a quick solution for this one that seems to work as I expect it. I simply wrote a tag handler for f:validateBean that checks if the attribute is a value expression. In that case this expression is directly set on the BeanValidator (new property validationGroupsExpression). BeanValidator evaluates this expression if it is set. Though this works for me with partial and full state saving I don't know if it is the way to go.
        Hide
        Michael Kurz added a comment -

        I did some further investigation on this one and set javax.faces.FULL_STATE_SAVING_VIEW_IDS to have full state saving for this view. Interestingly enough, it is not working too. I expected, that this would solve the issue. But the validator is not refreshed on building the view in render response. The validation group is always determined by the one in the state (and thus the one set on the first request).

        This leads to an interesting behavior: If the select box is checked on the initial request to this page the validator works as expected. Also when I check and uncheck the checkbox. So I guess in this case the validation group is always the same in the state but the validation still behaves correctly because the rendered attribute changes. If the checkbox is not checked on the initial request the validator does not work (validation group is always the default one).

        I noticed the same behavior in Mojarra 2.0.1.

        Is this the expected behavior?

        Show
        Michael Kurz added a comment - I did some further investigation on this one and set javax.faces.FULL_STATE_SAVING_VIEW_IDS to have full state saving for this view. Interestingly enough, it is not working too. I expected, that this would solve the issue. But the validator is not refreshed on building the view in render response. The validation group is always determined by the one in the state (and thus the one set on the first request). This leads to an interesting behavior: If the select box is checked on the initial request to this page the validator works as expected. Also when I check and uncheck the checkbox. So I guess in this case the validation group is always the same in the state but the validation still behaves correctly because the rendered attribute changes. If the checkbox is not checked on the initial request the validator does not work (validation group is always the default one). I noticed the same behavior in Mojarra 2.0.1. Is this the expected behavior?
        Hide
        Michael Kurz added a comment -

        Provided patch

        Show
        Michael Kurz added a comment - Provided patch

          People

          • Assignee:
            Unassigned
            Reporter:
            Michael Kurz
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development