[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423267#comment-13423267 ]
Neil Griffin commented on PORTLETBRIDGE-227: -------------------------------------------- Patch from Mike Freedman: add after line 73 in GenericFacesTestSuitePortlet.java: (removeAttribute statement is new line following code at line 72/73. actionRequest.setAttribute("verifyPreBridgeExclusion", "avalue"); super.processAction(actionRequest, actionResponse); + actionRequest.removeAttribute("verifyPreBridgeExclusion"); > 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) > [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 Description: 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. -- 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