This is similar to ICE-1900 (fixed for 1.8.2.GA), however the classes that were reworked to resolve this jira no longer exist in 2.0.

MORE SERIOUS.....

The invalid fields are blocking input submitted to the other input fields. For example, if you leave the Name empty (you get "Input is required" for FacesMessage and that field is invalid. However, you should still be able to enter values into the Comments box and have that come through to Server-side Backing Bean Values (at bottom of page). Invalid values are blocking other fields from updating backing bean.

This looks very much the same as the issue in ICE-1900 but the code has changed significantly between JSF 1.x and 2.x so a different approach is required rather than just porting the previous fix.

Currently, from my observations of Mojarra, the FacesMessage API has been extended to include this:

/**

• <p>Marks this message as having been rendered to the client.</p>
  *
• @since 2.0
  */
  public void rendered() { this.rendered = true; }

This method is used by the com.sun.faces.renderkit.html_basic.MessageRenderer to mark messages that have been rendered out to the client. Later on, logic in the RenderKitUtils uses this flag to identify FacesMessages as being successfully delivered to the client. At this point it looks like that the logic is not being applied in our case and the various messages (e.g. Validation messages) are being detected and logged.

Looks more and more like we'll need to make an adjustment to our own MessageRenderer and MessagesRenderers implementation. In Mojarra, these renderers execute very similar code to mark FacesMessages as being rendered. They both look similar to this:

... FacesMessage curMessage = (FacesMessage) messageIter.next();
if (curMessage.isRendered() && !messages.isRedisplay())

curMessage.rendered();
...

The FacesMessage.rendered() method is new to JSF 2.0 and allows the renderer to note that the FacesMessage has been rendered out, so that later, when RenderKitUtils checks to see if there are any FacesMessages that have not been rendered for some reason, the ones that have had rendered() called on them are suitably flagged. In our own compatibility mode renderers, we don't currently do this yet since the API is new.

Assigning to Ken to re-assign to the components team. I've added comments about what I believe needs to be done. I'll be happy to consult with whoever is going to be working on it.

New API integrated as mentioned by the Deryk.

Modified: D:\work\development\head\svn\ossrepo\icefaces\scratchpads\glimmer\compat\core\src\main\java\com\icesoft\faces\renderkit\dom_html_basic\MessageRenderer.java
Modified: D:\work\development\head\svn\ossrepo\icefaces\scratchpads\glimmer\compat\core\src\main\java\com\icesoft\faces\renderkit\dom_html_basic\MessagesRenderer.java
Sending content: D:\work\development\head\svn\ossrepo\icefaces\scratchpads\glimmer\compat\core\src\main\java\com\icesoft\faces\renderkit\dom_html_basic\MessageRenderer.java
Sending content: D:\work\development\head\svn\ossrepo\icefaces\scratchpads\glimmer\compat\core\src\main\java\com\icesoft\faces\renderkit\dom_html_basic\MessagesRenderer.java
Completed: At revision: 20196

Judy mentioned that rowSelector demo still shows messages:

12-Jan-2010 1:32:05 PM com.sun.faces.renderkit.RenderKitUtils renderUnhandledMessages
INFO: WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
sourceId=iceform:multipleSelection[severity=(ERROR 2), summary=(iceform:multipleSelection: Validatio
n Error: Value is not valid), detail=(iceform:multipleSelection: Validation Error: Value is not vali
d)]

I looked at the rowSelector demo, it seems like some validation being failed which queues a faces message, and on the page none of the message or messages being used, so that is why JSF tells that there is a message but never displayed which is expected behavior.