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