Neil Griffin created PORTLETBRIDGE-227:
------------------------------------------
Summary: Bridge Spec and TCK assume that the portlet container
implements the post-redirect-get design pattern
Key: PORTLETBRIDGE-227
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-227
Project: MyFaces Portlet Bridge
Issue Type: TCK Challenge
Components: TCK
Affects Versions: 2.0.0
Environment: Liferay Portal 6.1.x + Liferay Faces Bridge 3.1.x
Reporter: Neil Griffin
Assignee: Michael Freedman
[Test Challenger Name and Company]
Neil Griffin, Liferay, Inc.
[Specification Name(s) and Version(s)]
Portlet 2.0 Bridge for JavaServer™ Faces 1.2
[Test Suite Name and Version]
portlet-bridge-tck-main, v1.0.0
[Exclude List Version]
N/A
[Test Name]
TCK TestPage151 (requestMapRequestScopeTest)
TCK TestPage203 (JSF_ELTest)
[Complaint (argument for why test is invalid)]
Portlet containers like Pluto implement the post-redirect-get design pattern by
having the the ACTION_PHASE and RENDER_PHASE of the portlet lifecycle execute
in two separate user-agent requests. The first request is a POST
(ActionRequest), and the second request is a GET (RenderRequest). As a natural
by-product of this design, request attributes that were set during the
ACTION_PHASE do not survive into the RENDER_PHASE. On a related note, one of
the requirements of the bridge-request-scope is to ensure that non-excluded
attributes do indeed survive into the RENDER_PHASE.
The Liferay portlet container does not implement the post-redirect-get design
pattern. Instead, it executes the ACTION_PHASE and RENDER_PHASE of the portlet
lifecycle all within a single user-agent POST request. Because of this, the
Liferay portlet container maintains request attributes that were originally set
on the {@link ActionRequest} such that they automatically survive into the
{@link RenderRequest}.
Problem #1: The TCK TestPage151 (requestMapRequestScopeTest) performs some
checks to make sure that certain non-excluded request attributes don't survive
into the RENDER_PHASE. One of these attributes is named
"verifyPreBridgeExclusion" with value "avalue". Since the Liferay portlet
container does not implement post-redirect-get, it is not possible for the
bridge to programatically determine if the "verifyPreBridgeExclusion" attribute
should be removed.
Since the Bridge Spec assumes that the portlet container implements
post-redirect-get, it would be necessary for the bridge to pro-actively remove
non-excluded request attributes when running under Liferay Portal.
Details of problem: The following is an example list of String-based attributes
that are present in the Liferay Portal RenderRequest prior to the FacesContext
being constructed by the requestMapRequestScopeTest:
*
INVOKER_FILTER_URI="/chapter6_1_3_1TestsrequestMapRequestScopeTestportlet/invoke"
*
PORTLET_ID="chapter6_1_3_1TestsrequestMapRequestScopeTestportlet_WAR_bridgetckmainportlet"
* verifyPreBridgeExclusion="avalue"
In this example, the INVOKER_FILTER_URI and PORTLET_ID attributes (added by the
Liferay portlet container) need to be maintained, but the
"verifyPreBridgeExclusion" attribute needs to be removed. But to restate the
problem, it is not possible for the bridge to programatically determine which
one of these should be maintained and which should be removed.
Problem #2: The TCK TestPage203 (JSF_ELTest) performs some checks to make sure
that objects obtained from the bridge's ELResolver match expected values stored
as request attributes. One of these attributes is
"org.apache.myfaces.portlet.faces.testsuite.common.portletConfig", which is set
in the {@link GenericFacesTestSuitePortlet#initTestRequest(PortletRequest)}
method. Again, since the Liferay portlet container does not implement
post-redirect-get, it is not possible for the bridge to programatically
determine whether or not this value should be maintained since it is an
instance of javax.portlet.PortletConfig which the Spec requires to be removed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
