rich:tree changes its selected node in case of validation er

[koloale1]

Hello!
I have rich:tree ajaxSubmitSelection="true" and other input components with attached validators or convertors in one form:

<h:form id="contentForm">
<rich:tree
 nodeSelectListener="#{documentBean.processSelection}"
 adviseNodeSelected="#{documentBean.adviseNodeSelected}"
 ajaxSubmitSelection="true" switchType="ajax"
 value="#{documentBean.contentTree}" reRender="contentForm"/>

 <h:inputText id="age" value="#{documentBean.age}">
 <f:convertNumber/>
 </h:inputText>
 <rich:message for="age"/>
</h:form>

If I type some wrong number in the field and click other node in the tree than the validator generate message that will be shown, but the tree changes its current selected node to the new one. In the same time neither process selection listener nor adviseNodeSelected is called to somehow affect node selection in the tree.
I would expect that when validation phase fails than the tree doesn't change its state, or corresponding listeners are notified at least.

How do I can prevent changing a selected node in the tree in the case of validation errors?

Thank you,
Alexey

[nbelaevski]

Hello Alexey,

You are right, component state should remain unchanged. That's a bug: https://jira.jboss.org/jira/browse/RF-6732.

[rosmons]

I see this bug in Open state. Can I please know if there's any workaround for this?

[nbelaevski]

No workaround.

[rosmons]

Ok! thanks for the reply, but do you have any time-line on when we can expect a fix?

[nbelaevski]

This issue doesn't seem popular at all - no voters/watchers, so it's scheduled for "future" versions for now and not for the nearest one.

[rosmons]

I'm definitely interested in this bug being fixed because we're using the the tree component extensively in project. We already got RF-7323 fixed and are waiting for the next release. It would be really great if we can get this one too.
If it's possible to point me to the code where this might be happening I'll make the fix myself and post a patch which can then be reviewed and checked-in to the next bug fix release branch. in the meantime I'll try to debug and figure out where this happens.