Hi,
my context is Weld + JSF 2 (Mojarra 2.1.22) + RichFaces 4 + PB 3.1.2 final + GateIn 3.1 deployed on JBoss EAP 5.1 (with classloader isolation).
The problematic page:
- .xhtml containing several blocks (div) of (rich:messages + h:form)
- each block is processed through a a4j:commandLink
- the called bean adds zero or more FacesMessage during the process
- the message is displayed in the corresponding block in the page (partial update)
This works fine outside the portal environment.
Inside the portal:
- display page, click on a a4j:commandLink, message is displayed => OK
- after that, refresh the page, or browse to the initial URL of the page : all the rich:messages of the page (including the previously updated block) display the message => KO
- refresh again the page : now no message is displayed => expected behaviour, OK
Trying to find the differences between not-Ajax and Ajax context with relation to the Portlet Bridge, my debugger led me to this block of code in org.jboss.portletbridge.bridge.controller.Jsf20ControllerImpl::encodeMarkupResponse :
if (Bridge.PortletPhase.RESOURCE_PHASE == bridgeContext.getPortletRequestPhase()) {
saveMessages(facesContext);
scope.putAll(facesContext.getExternalContext().getRequestMap());
}
For the a4j:commandLink, the request is processed in a ResourcePhase, and then the FacesMessage are forcibly stored in the BridgeContext / scope, and then the messages are re-injected in the FacesContext when the page is refreshed / reloaded (and then displayed for a second time).
Am I correct in the analysis? What would you suggest for displaying messages in that environment: avoid FacesMessage and roll our own message lifecycle when submitting forms through the Rich Faces AJAX Control
Components?
