[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman resolved PORTLETBRIDGE-95.
-------------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
Fix in the manner described in the original filing. Put a complimentary fix in
the Portlet 1.0 bridge code though it was hitting this bug as it wasn't
checking for responseComplete before rendering. Added to be consistent and for
future code change (i.e. if we do add a check later). The 1.0 fix is not yet
checked-in.
> Trinidad GoLink/Faces CommandLink broken in bridge 2.0 if nav to another
> Faces view
> -----------------------------------------------------------------------------------
>
> Key: PORTLETBRIDGE-95
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-95
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 2.0.0-alpha, 2.0.0
> Reporter: Michael Freedman
> Assignee: Michael Freedman
> Fix For: 2.0.0
>
>
> Trinidad GoLinks and Faces CommandLink's that reference another Faces view
> ultimately are encoded as actionURLs but submitted via GETs (a hefs). This
> means when the action is processed a VIEW_STATE param isn't passed to the
> action -- leaving us in position in which the render that follows this action
> has a cached view but no (preserved) VIEW_STATE param. Since this render
> restores the view manually but then calls lifecycle.execute we get triupped
> up in Mojarra's lifecycle (restoreView handler) that sets responseComplete if
> the UIViewRoot has already been restored AND its not a postback (no
> VIEW_STATE param). With responseCompelte set, the bridge skips calling
> lifecycle.render -- thus the page generates no markup.
> The fix is to detect that the action is called with no VIEW_STATE param and
> to preserve a placeholder/dummy one so that the following render works. This
> should be safe as the VIEW_STATE param is updated at the end of render with
> the one that results from having saved the view -- thus overwriting the
> palceholder at a time when we remove the view from the cache.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
