Marking as Closed / Invalid as part of legacy ICEfaces 1.x, 2.x JIRA cleanup.

Note: This issue may be resolved in a newer ICEfaces release, available here: http://www.icesoft.org/java/downloads/icefaces-downloads.jsf

If the issue persists with the current ICEfaces release, please create a new JIRA for it.

Hello. My previous comment thought that ICE-4939 fixed this. But we've encountered it using 1.8.2 EE Patch 1. We've been able to apply the same patch already assigned to this issue to fix this. So, my request to close this issue was premature. We're still encountering this problem on unpatched releases of ICEfaces. Thanks.

With the changes made for ICE-4939, these changes are not necessary. Defining a value of -1 will make a session indefinate. This issue can be closed.

I've cleaned this up, so there's no duplication of code. The previous one had problems with it. Use the v2 patch instead of the first one

I've looked into this, and have a solution that works for me. It looks like the Monitor.isExpired() method is causing my grief. It was

public boolean isExpired() {

long elapsedInterval = System.currentTimeMillis() - lastAccess;
try {
int maxInterval = session.getMaxInactiveInterval();
// 4496 return true if session is already expired
Object o = session.getAttribute(POSITIVE_SESSION_TIMEOUT);

// Try to reset the max session timeout if it is -1 from a Failover on Tomcat...
// But if it was originally negative, it should stay that way.
if (maxInterval > 0) {
if (o == null)

} else {
if (o != null)

}
return elapsedInterval + 15000 > maxInterval * 1000;
} catch (Exception e)

}

So, the monitor is persisting the original value in the POSITIVE_SESSION_TIMEOUT session attribute. From the comments, it looks to be added to cater for behaviour in Tomcat, for when a Tomcat failover occurs . So, based on that, there is an instance where an application has a positive timeout and the Tomcat server hosting fails and the session gets moved to another Tomcat server which doesn't have the correct timeout set up. So this remedys it.

But, it is directly keeping me from what I want to do. And my application is running in Glassfish, not Tomcat and I don't anticipate using failover (for other reasons related to my application, not ICEfaces).

So, I will submit a patch that does the following:

• Defines a MonitorFactory class. It contains a single method, createMonitor. If the serverInfo for the HttpSession returns a Glassfish server, then a new instance of GlassfishMonitor is reused. Otherwise, the default Monitor is used.
• GlassfishMonitor extends Monitor, but overrides the isExpired method. It doesn't try to restore the session timeout from a session attribute. It just gets it and checks it against the elapsedInterval.

I thought this might be a good direction, as it looks like the Monitor might want to behave differently based on the Servlet Container hosting it. I haven't tried this out in Tomcat or any other container. But, this does allow my Glassfish server to behave the way I want without having to cater for workarounds added to support another container I'm not using.