Hi,
Your characterization of this problem is not correct.

I am running Liferay 4.3.1 on Tomcat 5.5 with Liferay deployed in webapps/ROOT and the sample-icefaces-sun-portlet keeps displaying the "User Session Expired" dialog. As you indicate, the portlet is unusable. I'm using Firefox 2.0.0.7 on OS X 10.4.

I tried the things mentioned on the forum (allowing cookies for localhost, restarting the browser, making sure the <listener> entry in web.xml is correct). Still does it.

Another problem I had with this portlet (perhaps related to Liferay): If the user is not logged in, exceptions are thrown when the FacesMessage is displayed. It's due to Liferay trying to get the companyId during the processing of the message. If the user is not logged in, the companyId is zero and this causes the exception.

Phil

I just discovered another possible clue.
It seems to be related to class reloading somehow.

I added reloadable="true" to the META-INF/context.xml file so Tomcat would reload classes if they change.
I then modified JobApplication.java to change the message that gets displayed (just to confirm the class was getting reloaded).
Every time I recompile the class, about 30 seconds later, the "User Session Expired" dialog popups up.

Hope this helps,
Phil

Phil,

I am the author of the sample-icefaces-sun-portlet. Did you try clearing your browser cache? Sometimes this can happen when there is a cached ICEfaces javascript resource.

--Neil

Liferay, Inc.

Did you try adding emptySessionPath to the server.xml? That way the cookies will still use ROOT.

<Connector port="8080" maxHttpHeaderSize="8192"

maxThreads="150" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" redirectPort="8443" acceptCount="100"

connectionTimeout="20000" disableUploadTimeout="true" emptySessionPath="true" />

I have replicated the problem in the case. I don't have a fix as of yet but Mike's comment about setting "emptySessionPath=true" does seem to be a viable workaround in the meantime. It certainly looks as if it's related to cookies management so I'll dig around deeper on that.

As for Phil's issue, the hot deploy problem is a known issue (see ICE-2152) and there is a potential fix in the pipeline. Clearing the session cookie while your developing is a temporary work-around during development cycles. The Session Expired pops up for a number of different reasons which makes it tough to tell exactly what's causing it.

I've spent a considerable amount of time looking at this and have decided that the workaround outlined in the case (setting "emptySessionPath=true" ) is the recommended solution.

The problem stems from the fact that when you move Liferay from the ROOT context to it's own context (e.g. /liferay-portal), you throw off how the ICEfaces Ajax communication operates. Requests going to the portal container all begin with (http://host:port/liferay-portal) and cookies/sessions/etc are all influenced. When you hot deploy an ICEfaces portlet, it automatically gets the root context so internally, all the Ajax communication gets routed accordingly (http://host:port/). Internally, the sessions and cookies do not match which causes the issue within the ICEfaces framework and, in the end, the Session Expired message.

I tried a number of things to see if I could work around it:

1) Included a META-INF/context.xml file that sets the context path and docBase from the portlet .war file.

<Context path="/liferay/myortlet" docBase="/myportlet" />

This does't work since the hot deploy always deploys it to root. There may be a way to get Liferay configured so that you could control where portlets get hot deployed but I couldn't easily find it.

2) Setting the virtual-path value in the liferay-portal.xml. The documentation says that the portal container will use this value as the request context it passes on to the portlet. I couldn't get this value to show up at all unless I hard-coded into the portal.properties file. Event then, passing a synthetic context to the portlet does not really help as the Ajax calls then become http://host:port/liferay-portal/... but the portlet is not really deployed to that context so you get an error.

My guess is that, in the end, unless you can get Liferay to deploy the portlets into the same context that Liferay is running in, you'll have trouble getting it to work. The workaround is simple and allows you to run Liferay in a context other than root. Resolving as won't fix.

I understand that this may be a workaround for Tomcat but what about other application servers such as OC4J.