s:validateEquality vs. s:decorate (with workaround)

[joblini]

Using the new <s:validateEquality> in conjunction with <s:decorate> results in the following exception:

<s:decorate template="/layout/edit.xhtml">
        <ui:define name="label">Password</ui:define>
        <h:inputText id="password" value="#{bean.name}"/>
</s:decorate>

<s:decorate template="/layout/edit.xhtml">
        <ui:define name="label">Password Verification</ui:define>
        <h:inputText id="passwordVerification" >
        <s:validateEquality for="password" />
        </h:inputText>
</s:decorate>

java.lang.IllegalStateException: forId must reference an EditableValueHolder ("input") component
        at org.jboss.seam.ui.validator.EqualityValidator$OtherComponent.<init>(EqualityValidator.java:168)
        at org.jboss.seam.ui.validator.EqualityValidator.validate(EqualityValidator.java:74)
        at org.richfaces.component.html.HtmlInputText.validateValue(HtmlInputText.java:35)
        at javax.faces.component.UIInput.validate(UIInput.java:867)

[joblini]

Problem is that EqualityValidator line 74 cannot find the component

UIComponent otherComponent = component.findComponent(forId);

As per JSF 1.2 API, findComponent will

search up the parents of this component. If a NamingContainer is encountered, it will be the base for the search.

Since s:decorate implements the NamingContainer interface, findComponent fails to locate the forId, and returns null, resulting in the exception seen above.

A workaround is to specifiy the full client id, with a leading :, like this:

<s:validateEquality for=":#{rich:clientId('password')}" />

This results in something similiar to for=":user:j_id174:password"

[joblini]

Noticed that this has previously been reported in JBSEAM-3676.