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
Create two separate Glassfish domains, and deploy an ICEfaces application into each of them. The two domains are completely separate, with their own ports. They are standalone domains (they are not in a cluster).
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?
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?
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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.
Show
Ed Hillmann
added a comment - 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.
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.