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
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.
