Attached a sample project to demonstrate the issue.

Steps to reproduce the problem:
1. Enter "asdf" in both text fields
2. Press the button. Notice the two correctly shown error messages.
3. Clear the second text field.
4. Press the button again. Notice that still BOTH error messages are shown, even if the second field is now valid!

Options which don't show the problem:

• remove <f:ajax disabled="true"/> tag OR
• remove icefaces-ee.jar OR
• set redisplay=false on h:message: <h:messages redisplay="false"/>

All of these options are not feasible workarounds in our case.
<f:ajax disabled="true"/> is needed to trigger a full page refresh in a Portal environment

Fixed testcase

<icecore:config messagePersistence="true"/> may be useful here.

Adrian has verified that ajax disabled=true is disabling ajax interaction, but there is still a problem with message persistence.

It also happens with <f:attribute name="DISABLE_CAPTURE_SUBMIT" value="true" /> but without <f:ajax disabled="true"/>.

So now it seems to be pretty clear that the problem is message persistence in the case of normal POST requests.

Perhaps the new configurability added in 3.0 for Message Caching can be used as a suitable workaround for this.

Found the logic flaw. When doing an Ajax postback, or a fileEntry post that mimics one, the PartialViewContext.executeAll property is set appropriately depending if the submitted javax.faces.partial.execute is @all or not. But when a full page submit is made, that does not use Ajax, then the whole component tree is being executed, but PartialViewContext.executeAll is not set to true, and instead remains false. This tells our FacesMessagePhaseListener that it should propagate FacesMessage objects forward. So we need to first check PartialViewContext.partialRequest to see if executeAll is applicable, and when not in a partialRequest then know we're fully executing.

icefaces3 trunk
Subversion 27299