Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Won't Fix
-
Affects Version/s: 1.8.2-EE-GA_P01
-
Fix Version/s: 1.8.3, 1.8.2-EE-GA_P02
-
Component/s: None
-
Labels:None
-
Environment:Linux dingbat 2.6.18-128.el5 #1 SMP Wed Jan 21 08:45:05 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
Firefox 3.6
IE 8
-
Workaround Exists:Yes
-
Workaround Description:
Description
Individually, a browser on a client can use each on their own without error.
However, we have found the following scenario.
1) Connect to the application in domain A. Call this Browser A.
2) On the same client machine, open another Tab/Window/Session in the browser and connect to the application in domain B. Call this Browser B.
3) Once Browser B has connected, Browser A displays the message we display when an Ice.onSessionExpired event is received. So Browser A's session has expired.
4) One the OK button is clicked in Browser A in the dialog with the session expiry message, Browser B's session is expired and displays the message.
Surely the applications running on different domains on the same host machine should be available to the same client without this sort of impact?
-
- icefacesBugReport_src.zip
- 10 kB
- Ed Hillmann
-
Hide
- icefacesBugReport-1.0-SNAPSHOT.war
- 5.73 MB
- Ed Hillmann
-
- META-INF/MANIFEST.MF 0.1 kB
- WEB-INF/faces-config.xml 0.5 kB
- WEB-INF/sun-web.xml 0.5 kB
- WEB-INF/navigation.xml 0.3 kB
- WEB-INF/classes/.../BackingBean.class 0.7 kB
- WEB-INF/classes/.../CustomServlet.class 2 kB
- WEB-INF/managed-beans.xml 0.5 kB
- WEB-INF/lib/log4j-1.2.14.jar 359 kB
- WEB-INF/.../backport-util-concurrent-2.2.jar 319 kB
- WEB-INF/lib/commons-fileupload-1.2.1.jar 56 kB
- WEB-INF/lib/commons-logging-api-1.1.jar 44 kB
- WEB-INF/lib/jxl-2.6.8.jar 706 kB
- WEB-INF/lib/commons-logging-1.1.jar 52 kB
- WEB-INF/lib/icefaces-1.8.1-sv-1.3.jar 1.06 MB
- WEB-INF/.../icefaces-facelets-1.8.1-sv-1.3.jar 596 kB
- WEB-INF/lib/commons-beanutils-1.8.0.jar 226 kB
- WEB-INF/lib/commons-collections-3.2.jar 558 kB
- WEB-INF/.../icefaces-comps-1.8.1-sv-1.3.jar 1.93 MB
- WEB-INF/lib/FastInfoset-1.2.2.jar 285 kB
- WEB-INF/lib/el-api-1.0.jar 24 kB
- WEB-INF/lib/commons-digester-1.8.jar 140 kB
- WEB-INF/web.xml 4 kB
- index.jsp 0.2 kB
- icefacesBugReport.xhtml 0.8 kB
- META-INF/maven/.../icefacesBugReport/pom.xml 4 kB
- META-INF/maven/.../pom.properties 0.1 kB
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Please note, when I said "deploy an ICEfaces applciation into each of them", the same ICEfaces application is deployed into each Glassfish domain. I just want to be clear. It's not that each domain gets a different WAR file. The same WAR file is deployed into each domain.
Sorry if I wasn't clear.
The sessions are likely not actually expiring, rather ICEfaces is tracking the session expiry in a way that is confused by the similar URLS.
I have reproduced this using Tomcat 6: configure two copies of Tomcat, one on port 8080, the other on port 18080. Install auctionMonitor to both and observe the "session expired" reported in one browser window when connecting to both simultaneously.
Upon further investigation, it appears that the session actually is expiring. Most browsers associate the cookie only with the host and the path, not with the port. Therefore two different applications on different ports but with the same path will receive conflicting JSESSIONID cookies. This conflict is inherent to the Servlet Session strategy and is not specific to ICEfaces.
One option is to use URL rewriting rather than cookies for maintaining the session. This can be configured in the web application in a server-specific way.To force tomcat to use URL rewriting rather than the JSESSIONID cookie add a META-INF/context.xml file to the .war containing:
<?xml version="1.0" encoding="UTF-8"?>
<Context cookies="false">
</Context>
(This feature is only recently supported, see ICE-5871, so a current ICEfaces build is required.)
Alternatively, it may be possible to augment the server response with set-cookie2:
Both Safari and Firefox failed to associate the JSESSIONID cookie with a specific port.
Related JIRA ICE-2565 with cookie behavior in Portals.
Configuration for GlassFish in sun-web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<sun-web-app>
<session-config>
<session-properties>
<property name="enableCookies" value="false" />
</session-properties>
</session-config>
</sun-web-app>
Servlet 3.0 allows the session ID cookie name to be configured:
WEB-INF/sun-web.xml may work better:
<?xml version="1.0" encoding="UTF-8"?>
<sun-web-app>
<session-config>
<session-properties>
<property name="enableCookies" value="false"/>
<property name="enableURLRewriting" value="true"/>
</session-properties>
</session-config>
</sun-web-app>
Verified that auctionMonitor synchronous features work when cookies are disabled for two servers on different ports. Push only works in one of the applications, however.
I've confirmed this as well. I've tested out deploying the applications into each domain with different root contexts. And the cookies were unique. But only one of the applications received server push notifications.
I understand (I think I do, anyways!) that this is because of the server connection limits imposed by browsers. The only viable option while these limits exist will be to present the server hosting each domain as unique. As this is only an issue for our internal development/testing environments, we could do this using virtual servers.
Unless I've misunderstood the problem, though, it doesn't sound like this is an ICEfaces bug. So, I'll leave it up to you as to whether you want to close out this issue. I guess if you keep it open for future work, it could be changed as an enhancement.
The customer has accepted our suggestion to use the approach of creating separate (virtual) domains. Instead of this:
myhost.org:8080/context1
myhost.org:8085/context2
do this:
webapp1.myhost.org/
webapp2.myhost.org/
While there may be some things we could do from the ICEfaces side, they'd likely require a fair degree of customization. Resolving as Won't Fix as it's actually a configuration change for the developer.
This is a sample application with which we can recreate this issue. I've included the WAR file, as well as the source used to construct it.
One note: if each domain uses a different context root for the deployed application, then we don't get the error. However, this is not a feasible long-term solution for us.