Panel 3 has some buttons that are enabled on table row selection and some buttons allow move up /down/ delete of rows

It mostly works well. There is just one small problem.

Error messages related to the fields in the Panel1 disappear from <rich:messages ajaxRendered="true" id="mainmessages" /> if the table in Panel2 has a selection listener and the table is selected on a row that is not currently selected.

Any suggestion?

I was able to get some kind of a partial solution by changing the listener configuration to

What do you mean by - explicitly calling for a render of your messages when you want it rendered?

I would like to understand whether the <rich:messages /> which are geneerated on the change event for field1 are expected to be remembered later when say the table selectionchange event happens or when the tabular field validators are invoked.

you have ajaxRendered="true" in your rich:messages component. From the vdl-doc, ajaxRendered:

Defines, whether the content of this component must be (or not) included in AJAX response created by parent AJAX Container, even if it is not forced by render list of ajax action. Ignored if component marked to output by some Ajax action component.

IIRC the message is discarded once it's written to the response. So if you want to keep it around, don't render it.

Setting ajaxRendered="false" also did not solve the problem. I had tried that earlier.

What I understand is that a FacesContext which holds the message is tied to a request and response sequence.

In a form with behind the scenes ajax request/responses there are multiple FacesContext instances.

But that said its not a problem with simpler forms that use ajax as in the validation examples in the showcase.

Richfaces must be doing something smart behind the scenes. But it did not work here in this case I think.

I am sure I can provide workarounds. Not sure if I should.

e.g. 1. each of my validator methods that are defined in the managed bean #{tableD could store the messages with clientId as key in a map inside the managed bean just before throwing the ValidatorException. Each Validator method could after doing its own validation just before throwing the exception additionally find the UIInput corresponding to the clientid in the map. Check if the input is valid- UIInput.isValid(). If not it could use the message and add it into facesContext if the message is not already there. If the input is valid it could clear the entry in the map.

2. Using a custom FacesContextFactory, FacesContext and some generic code override the FacesContext.release method to do somehow the same possibly by injecting the manged bean into the faces context.

However my guess is if it works for most forms it should without all this extra work.

How about executing in your ajax calls all form elements that you want to retain there associated messages. The messages would be re-validated on every ajax request then, and the messages would be retained.