[
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
