[jira] [Resolved] (PORTLETBRIDGE-227) Bridge Spec and TCK assume that the portlet container implements the post-redirect-get design pattern

["Michael Freedman (JIRA)" <de...@myfaces.apache.org>]

     [ https://issues.apache.org/jira/browse/PORTLETBRIDGE-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Freedman resolved PORTLETBRIDGE-227.
--------------------------------------------

       Resolution: Fixed
    Fix Version/s: 3.0.0
                   2.0.1

Updated portlet.xml to put event tags in correct (syntax) order.
                
> 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
>             Fix For: 2.0.1, 3.0.0
>
>
> [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