So I've spent a bit of time on this and have the following information:

Deploying portlets to JetSpeed is interesting. There is a "hot" deploy folder under webapps/jetspeed/WEB-INF/deploy and a second one under webapps/jetspeed/WEB-INF/deploy/local. According to the README.txt in both locations, you're supposed to be able to drop portlet archives (.war) files in to these folders and have them deployed. The caveat is that in the parent directory (deploy), the archive name must start with "jetspeed" (e.g. jetspeedchat.war vs chat.war). The child directory (deploy/local) is not supposed to require this.

What I've found is that I can hot deploy to the "deploy" folder by adding the "jetspeed" prefix but I have not been able to deploy to the "deploy/local" directory because it doesn't appear to load or run the servlets configured in the web.xml. There may be other framework necessities that don't get loaded properly as well.

In any case, adding "jetspeed" to the name deploying to the "deploy" directory mostly works.

I managed to deploy both the component-showcase and the chat samples and run them. But I could only get them to work with Safari and IE. Firefox gets a "Session Expired" right on the initial load. Further investigation indicates that our own internal ICEfaces ID is being generated twice and causing a mismatch when a comparison is done. I added some debugging output to a couple of the classes and this is what happens:

FIREFOX

SessionDispatcher.sessionCreated: 5E284534DB77D3C4526339492E5DC4C1
MainSessionBoundServlet.MainSessionBoundServlet:
generated id: zs_9Ey-OAnpt0OIWOUA5lQ
session id : 5E284534DB77D3C4526339492E5DC4C1
SessionDispatcher.sessionCreated: D7B513E73C7D687D63011EFE437ED428
MainSessionBoundServlet.MainSessionBoundServlet:
generated id: -CQ80wGGlZwr5IW28qd1nA
session id : D7B513E73C7D687D63011EFE437ED428
IDVerifier.service:
ICEfaces ID: zs_9Ey-OAnpt0OIWOUA5lQ
Session ID : -CQ80wGGlZwr5IW28qd1nA
SessionExpired.serializeTo: could not verify ICEfaces ID
IDVerifier.service:
ICEfaces ID: zs_9Ey-OAnpt0OIWOUA5lQ
Session ID : -CQ80wGGlZwr5IW28qd1nA
SessionExpired.serializeTo: could not verify ICEfaces ID

SAFARI, IE

SessionDispatcher.sessionCreated: 664717A78E0DF8EAAC836E9ACCB73674
MainSessionBoundServlet.MainSessionBoundServlet:
generated id: SykwWWVFczJF6ftfuETo-w
session id : 664717A78E0DF8EAAC836E9ACCB73674
IDVerifier.service:
ICEfaces ID: SykwWWVFczJF6ftfuETo-w
Session ID : SykwWWVFczJF6ftfuETo-w

For some reason, with Firefox, there are two sessions created causing two ICEfaces IDs to be generated. The browser already has the first ID as a request attribute and when it sends this back, it doesn't match anymore because the second id has been generated and stored.

After further study, it turns out that, for some reason, when Firefox is running against JetSpeed and requests the bridge code (e.g. /jetspeedchat/xmlhttp/1201569971060/icefaces-d2d.js) it's not including the JSESSIONID cookie. When the server sees this request without a valid session cookie, it assumes that a new session should be created and then the whole thing goes off the rails as described above. At this point, since IE and Safari don't exhibit this behaviour, I assume it has something to do with how Firefox is handling the cookies for the different paths. The hunt goes on.

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).