Bridge ViewHandler incompatible with Trinidad: if access as servlet
restoreView fails to restore proper instance
-----------------------------------------------------------------------------------------------------------------
Key: PORTLETBRIDGE-151
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-151
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0-alpha, 1.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman
Though the bridge should merely delegate all non-portlet calls in its
ViewHandler Impl, it doesn't. This causes the following peculiar problem. The
bridge's createView() method causes a PortletNamingContainerUIViewRoot to be
created/returned when accessed from a servlet using the code block that
temporarily substitutes the component (type) with this class. Trinidad's
restore keeps cached versions of the UIViewRoot -- but rather than use it it --
it claims its worried about message/events still on the object. It duplicates
it and restores the state into the duplicate. Unfortunately the way it
duplicates is is to merely call createComponent (using the component type). As
we only temporarily set the component type (class) they duplicate/create the
wrong class -- and then restore into it. We have seen situations when Trinidad
runs under a rich client layer that PPRs don't render (in the servlet case)
because of this -- the UIViewRoots rendered flag is incorrectly set to true
because of the bad restore.
Note: Though we haven't seen anolmolies when running just with Trinidad
(nonPPR) we expect folks will encounter some problems and hence anyone running
the bridge with Trinidad (bridge 1.0 or 2.0) should pick up this fix.
Simple/basic fix is to have the bridge's ViewHandler, always and only delegate
when not a portlet request. This effectively works around the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
