[jira] Resolved: (PORTLETBRIDGE-182) Portlet Bridge 3.0.0 -- renderURLs shouldn't carry forward scope by default

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

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

Michael Freedman resolved PORTLETBRIDGE-182.
--------------------------------------------

       Resolution: Fixed
    Fix Version/s: 3.0.0-alpha

I leveraged the special QS param that signals to encodeActionURL that its encoding a bookmarkable url.  If the value of this QS param is true then the scope isn't preserved (we add a new different param to the url being generated that is recognized in the bridge's render)  If the value is false we still create the render url but without this extra param -- hence the bridge will preserve the scope.  This later is done/supported as TCK tests rely on this to do render redisplays (within the scope).

> Portlet Bridge 3.0.0 -- renderURLs shouldn't carry forward scope by default
> ---------------------------------------------------------------------------
>
>                 Key: PORTLETBRIDGE-182
>                 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-182
>             Project: MyFaces Portlet Bridge
>          Issue Type: Bug
>          Components: Impl
>    Affects Versions: 3.0.0-alpha
>            Reporter: Michael Freedman
>            Assignee: Michael Freedman
>             Fix For: 3.0.0-alpha
>
>
> Late in the game the bridge impl changed (2.0) whereby a bridge scope is always created on any request that there isn't one (in the case you are in a render or resource request we cache this in a session attr).  Because of this renderURLs created via encodeActionURL might retain their scopes across submissions.  This doesn't seem like the reasonable default.  With Portlet 3.0.0 they added a concept of a bookmarkable url -- which makes it more common for a faces app to create a render url (prior versions could only do it using the special portlet:render? syntax).  So we need to fix the encodeActionURL to mark renderURLs as not preserving the scope.  

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira