[PORTLETBRIDGE-151] Bridge ViewHandler incompatible with Trinidad: if access as servlet restoreView fails to restore proper instance

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.0.0, 2.0.0-alpha
• Fix Version/s: 1.0.1, 2.0.0-beta
• Component/s: Impl
• Assignee: Michael Freedman
• Reporter: Michael Freedman
• Created: 14/Jul/10 21:47
• Updated: 29/Jul/10 15:50
• Resolved: 29/Jul/10 15:50

Description

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.