Details
-
Type: New Feature
-
Status: Closed
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 1.7DR#3
-
Fix Version/s: 2.0-Beta1
-
Labels:None
-
Environment:Portal portlet
-
Workaround Description:Use auto session extender ( see: http://support.liferay.com/browse/LEP-3241 )
Description
The current behaviour of ICEfaces in a portal environment is for the initial request to go through the portal container, generating a RenderRequest. The RenderRequest is handled by our own MainPortlet which routes it to the MainServlet and the rest of the ICEfaces framework. In a portal environment, typical client interaction with a portlet would also go through the portal container, generating an ActionRequest. Currently, ICEfaces does not do this. All client interaction is done via Ajax and the resulting requests go straight to our own framework servlets, bypassing the portal container. This has a number of consequences for the developer (some of which are documented in other JIRA cases):
- Session last accessed time is not updated properly
- ActionRequest/ActionResponse APIs are not available to the portlet developer preventing programmatic control of things like portlet modes (view, edit, help, etc) and window states (minimized, maximized, etc)
- Session last accessed time is not updated properly
- ActionRequest/ActionResponse APIs are not available to the portlet developer preventing programmatic control of things like portlet modes (view, edit, help, etc) and window states (minimized, maximized, etc)
Issue Links
- blocks
-
ICE-2294 JSR-168 WindowState changes unsupported
- Open
-
ICE-1672 JSF navigation rules are not informing the portal of a change in portlet modes
- Closed
-
ICE-2519 Session access in portlets via Ajax does not change portlet session lastAccessedTime
- Closed
- depends on
-
ICE-3420 Support for JSR 329 - the JSF Portlet 2.0 Bridge specification.
- Closed
The user session is no more than the session associated with the web-application deployed in the ROOT context, namely the portal implementation. The portlet session is backed by a servlet session associated to the web-application corresponding to the deployed WAR.
So, I attempted to fix this issue by creating an action URL (PortletResponse.createActionURL) and then invoke it every time portlet's corresponding "lastAccessTime" is touched. But because every action request will trigger a render in all portlets this solution is not viable.
The solution might be to just monitor the portal session and when is about to expire invoke an action URL that would force a page refresh and consequently update the "lastAccessTime" time of the portal session (== ROOT context). The good thing is that the implementation could be isolated just to the MainPortlet class.