I have experienced an issue with the portlet bridge 3.0 Beta and new scope "view".
The managed bean is always instantiated during the restoreView phase. The managed bean saved in the new map viewMap available on the UIViewRoot is not properly restored.
This is related to the clientId of the UIViewRoot (class PortletNamingContainerUIViewRoot).
JSF 2 uses the view root client id to save/restore the state of UIViewRoot. During the saving (after the render phase), the client id of UIViewRoot is set to pb_xxxxx (the default id j_id1 is overridden by the method getContainerClientId called from the method UIComponent.getClientId()).
public String getContainerClientId(FacesContext context)
ExternalContext externalContext = context.getExternalContext();
String rootId = getId();
if(null == rootId || !rootId.startsWith("pb"))
However, during the restoreViewPhase, the state manager uses UIViewRoot.getClientId to get the state of the viewRoot.
Class StateManagementStrategyImpl, method restoreView
String cid = target.getClientId(context.getFacesContext());
Object stateObj = state.get(cid);
At this point, the getClientId() return the default id j_id1 therefore, the UIViewRoot state can not be restored properly!
I am wondering why the UIViewRoot defined in portlet bridge 3.0 (PortletNamingContainerUIViewRoot) is different than the one defined in portlet bridge 2.1.0 (class UIPortletAjaxViewRoot)
If I use UIPortletAjaxViewRoot instead of PortletNamingContainerUIViewRoot, I do not experience the issue anymore.
To my opinion, the portlet bridge 3.0 should use UIPortletAjaxViewRoot (UIPortletAjaxViewRoot seems to be buggy)
This is resolved in the current master on github, and will be part of Beta4.
The problem was actually not related to the NamingContainer, but was due to the Bridge comparing portlet modes and detecting a change, when there wasn't one, which meant the Bridge Request Scope was cleared instead of being used.