[
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
