Resolving as Won't Fix and supplying a configuration workaround.
The workaround is to modify the [jetspeed-root]/conf/server.xml file and add the emptySessionPath="true" attribute to the <Connector> element. It should look something like this:
<Connector port="8080" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" emptySessionPath="true"/>
Doing this ensures that a single JSESSIONID cookies is mapped to root for all requests. JBoss Portal has this set as default (http://jira.jboss.org/jira/browse/JBAS-1400). Without this set, you'll get session id cookies for new paths.
For example:
/...
/jetspeed/...
Because of JetSpeed's deployment mechanism, you have to prefix with the .war file with jetspeed (e.g. jetspeedchat.war). The other deployment mechanism, which doesn't require this prefix, doesn't work for ICEfaces because it won't start our servlets, etc (http://issues.apache.org/jira/browse/JS2-606). Doing this means that the resources we pull out of the portlet, like our bridge, start with the portlet's context pat:
/jetspeedchat/...
The reason this is an issue is that the browsers seem to be path matching differently. Safari and IE seem to see /jetspeed and /jetspeedchat as the same and so respond with both JSESSIONID cookies. Firefox does not equate /jetspeed/... and /jetspeedchat/... so the first request (typically for the bridge /jetspeedchat/xmlhttp/1201629453813/icefaces-d2d.js) only includes the cookie mapped to "/". Tomcat sees the new path (/jetspeedchat) and generates a new session. As mentioned in the original comment, this causes a mismatch of ICEfaces ids in the ICEfaces framework and results in the dreaded User Session Expired popping up.
There may be another workaround where you can explicitly set the context in Tomcat but I didn't experiment with it (http://issues.apache.org/jira/browse/JS2-104).
Resolving as Won't Fix and supplying a configuration workaround.
The workaround is to modify the [jetspeed-root]/conf/server.xml file and add the emptySessionPath="true" attribute to the <Connector> element. It should look something like this:
<Connector port="8080" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" emptySessionPath="true"/>
Doing this ensures that a single JSESSIONID cookies is mapped to root for all requests. JBoss Portal has this set as default (http://jira.jboss.org/jira/browse/JBAS-1400). Without this set, you'll get session id cookies for new paths.
For example:
/...
/jetspeed/...
Because of JetSpeed's deployment mechanism, you have to prefix with the .war file with jetspeed (e.g. jetspeedchat.war). The other deployment mechanism, which doesn't require this prefix, doesn't work for ICEfaces because it won't start our servlets, etc (http://issues.apache.org/jira/browse/JS2-606). Doing this means that the resources we pull out of the portlet, like our bridge, start with the portlet's context pat:
/jetspeedchat/...
The reason this is an issue is that the browsers seem to be path matching differently. Safari and IE seem to see /jetspeed and /jetspeedchat as the same and so respond with both JSESSIONID cookies. Firefox does not equate /jetspeed/... and /jetspeedchat/... so the first request (typically for the bridge /jetspeedchat/xmlhttp/1201629453813/icefaces-d2d.js) only includes the cookie mapped to "/". Tomcat sees the new path (/jetspeedchat) and generates a new session. As mentioned in the original comment, this causes a mismatch of ICEfaces ids in the ICEfaces framework and results in the dreaded User Session Expired popping up.
There may be another workaround where you can explicitly set the context in Tomcat but I didn't experiment with it (http://issues.apache.org/jira/browse/JS2-104).