Assigning to me and linking to related SalesForce case.

After a fair amount of testing, it turned out that Liferay.Session.setCookie() has a couple of issues and is not feasible for our purposes:

1) It behaves differently depending on which user you are logged in as. For example, it works when logged in as Bruno (Administrator) but not as John (Regular User). There is some security component here that prevents this from being a general solution.

2) When logged in as the proper user, setCookie works fine until you allow the warning banner to appear. For example, you can maintain activity with the portlet and the warning banner is suppressed. If you cease activity, the warning banner will appear at the set time (by default this is 1 minute before session expiry) as designed. However, if you click the 'Extend' button, the setCookie method no longer has the desired effect, the warning banner will appear no matter what level of user activity is done.

The only other item of note is the setting of the session-timeout value. This is normally done in the web.xml of the portlet .war files. However the value used by the client-side timer is retrieved from Liferay's web.xml file (for the Tomcat distribution, this is webapps/ROOT/WEB-INF/web.xml). In order to align the session timeout values for the client and the backend, you must ensure that these values are the same.

A fix for issue #1 noted above looks to be covered by this case:

http://issues.liferay.com/browse/LPS-16371

I've opened a case in Liferay's system for issue #2:

http://issues.liferay.com/browse/LPS-17624

In any event, neither problem is solved for current users of ICEfaces. Following a variety of testing, the following solution has been implemented.

A class called PortletListener has been implemented as a SystemEventListener, much like how we use BridgeSetup to add Javascript to the page already. It checks to ensure that the current request is an ICEfaces view, a PortletRequest, and more specifically, the Liferay is involved and then adds the following snippet of JavaScript:

if(!extendLiferayClientTimer){

var extendLiferayClientTimer = function() {
if(Liferay.Session)

};

if (Liferay)

}

The code registers a small function that, if possible, calls Liferay.Session.extend() with each client submission. This ensures that the banner is reset for every client interaction that ICEfaces does.

Note: The one drawback of this is that the Liferay.Session.extend() call makes a separate request to the server. This is part of the Liferay code and is currently unavoidable. The request however is small and innocuous. This change works with both Liferay 6.0.6 as well as 5.2.3 (the community versions) so should help customers running on existing implementations.

Changes have been checked into both:

ossrepo/icefaces2/trunk/icefaces
ossrepo/icefaces2/branches/icefaces-2.0.x-maintenance/icefaces

Resolving as fixed.

It was decided that, since these were basically Liferay bugs that we were trying to workaround, we would be better served to have it in the PortletFaces Bridge if possible and, until such time as it was generally available, we'd offer the solution written up as a workaround in this JIRA. I've reverted the originally committed changes.

Overview
--------

There is basically one thing that we are trying to do and 2 bugs that are impacting it. We need to be able to update Liferay's client-side system for notifying users when the session is about to expire. By default, the session timeout value is 30 minutes and the session timeout warning is 1 minutes. So in the absence of any activity, after 29 minutes, Liferay will display a banner warning you that the session will expire in 1 minute and provide an "Extend" button which resets the timer.

The challenge is that certain requests, like ICEfaces Ajax requests, do not automatically re-adjust Liferay's client timer. So interacting with an ICEfaces portlet will not prevent the warning banner from displaying after 29 minutes no matter how much activity there is. Liferay's recommendation is to call Liferay.Session.setCookie() so that the cookie used to adjust the timer is properly updated. The way to do this with ICEfaces is to register a function with the ICEfaces JavaScript API that gets called for each request. For example:

<script>
if(!extendLiferayClientTimer){
var extendLiferayClientTimer = function() {
if(Liferay.Session)

};
if (Liferay)

}
</script>

NOTE: It's important to know that call to extend() makes a small Ajax request to the server to ensure that the server session is updated at the same time as the client. This extra request is in addition to the ICEfaces request so it's not as efficient a network bandwidth perspective as simply calling setCookie().

Implementation
--------------

There are a number of different ways to add the script to your portal page. You can use Liferay's themes or simply manually add the script to any views that require it. One way we suggest to implement this feature in your own applications is to create a SystemEventListener that automatically adds the script to the head section of the page during the PreRenderViewEvent. Below is an example of a Java class that implements the SystemEventListener interface and adds the code to the <head> section of the page. The PortletFaces Bridge takes care of ensuring that it gets properly inserted using Liferay APIs:

package org.icefaces.impl.event;

import org.icefaces.util.EnvUtils;

import javax.faces.component.UIComponent;
import javax.faces.component.UIOutput;
import javax.faces.component.UIViewRoot;
import javax.faces.context.FacesContext;
import javax.faces.context.ResponseWriter;
import javax.faces.event.AbortProcessingException;
import javax.faces.event.SystemEvent;
import javax.faces.event.SystemEventListener;
import java.io.IOException;

public class PortletListener implements SystemEventListener {

public void processEvent(SystemEvent systemEvent) throws AbortProcessingException {
final FacesContext fc = FacesContext.getCurrentInstance();

if (!EnvUtils.isICEfacesView(fc))

if (!EnvUtils.instanceofPortletRequest(fc.getExternalContext().getRequest()))

if (EnvUtils.isLiferay())

}

public boolean isListenerForSource(Object o)

private UIComponent getLiferayScriptComponent() {

UIOutput liferayScript = new UIOutputWriter() {

public void encode(ResponseWriter writer, FacesContext context) throws IOException {

writer.startElement("script", this);
writer.write("if(!extendLiferayClientTimer){");
writer.write(" var extendLiferayClientTimer = function() {");
writer.write(" if(Liferay.Session)

");
writer.write(" };");
writer.write(" if (Liferay)

");
writer.write("}");
writer.endElement("script");
}
};

liferayScript.setTransient(true);
return liferayScript;
}
}

Once you've added the class to your code, you also need to specify the listener in your faces-config.xml file:

<application>
...
<system-event-listener>
<system-event-listener-class>org.icefaces.impl.event.PortletListener</system-event-listener-class>
<system-event-class>javax.faces.event.PreRenderViewEvent</system-event-class>
</system-event-listener>
...
</application>

Since this issue could be fixed at any time with a Liferay release, and that the Liferay release would likely necessitate additional changes to the technique being used to ensure the portlet session doesn't expire erroneously when only JSF-ajax updates are occurring, it is not appropriate for inclusion directly in either ICEfaces or the PortletFacesBridge at this time.

Users are recommended to use the documented work-around until such time as Liferay resolves and releases a fix for http://issues.liferay.com/browse/LPS-17624.

Should script be updated to call Liferay.Session.set('sessionState', 'active');

as per http://issues.liferay.com/browse/LPS-17624

?

Also api has changed to onBeforeSubmit instead of onSubmitSend