FACES-2679 and FACES-2684, over the years we have found it necessary to have an extensions points for supporting different portlet containers. One such extension point is providing the ability for determining attributes that are to be "excluded" from the Bridge Request Scope.
As described in Section 5.1.2 of the JSR 329 Spec titled "Managing Lifecycle State", the Bridge Request Scope feature solves several problems, such as:
A. Enables @javax.faces.bean.RequestScoped managed beans and FacesMessages to survive from the ACTION_PHASE of the portlet lifecycle to the RENDER_PHASE.
B. Supports the "redisplay" use-case (Action->Action Scope)
- Step 1: Place two non-Ajax JSF portlets on a portal page (A & B)
- Step 2: Submit a form via portlet A that populates a @RequestScoped managed bean with values from form fields
- Step 3: Submit a form via portlet B
- Step 4: Ensure that the values from Step 2 are redisplayed in the form fields
The JSR 329 Spec describes the Bridge Request Scope as inclusive, meaning that objects living in ExternalContext.getRequestMap() are to be included. However Section 188.8.131.52 titled "Excluding Attributes from the Bridge Request Scope" describes requirements for certain attributes that must be excluded from the Bridge Request Scope.
This task serves as a proposal for promoting com.liferay.faces.bridge.scope.RequestAttributeInspector, com.liferay.faces.bridge.scope.RequestAttributeInspectorWrapper, and com.liferay.faces.bridge.scope.RequestAttributeInspectorFactory to the javax.portlet.faces package in the Bridge API:
In addition, the Spec will require that the factory delegation chain pattern be supported by bridge implementations. As a matter of convenience to the portlet developer, it is best to use a zero-config mechanism for registering factories, so the bridge implementation must recognize the bridge:request-attribute-inspector-factory element as a child of the factory-extension element of faces-config.xml descriptors.