Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.6DR#2
-
Component/s: Framework
-
Labels:None
-
Environment:Tomcat, websphere, weblogic, jboss
-
ICEsoft Forum Reference:
-
Support Case References:
Description
Note that in JBoss environments, this is generally an indication that there is no HttpSessionListener registered to be notified of the session creation, and thus, no handler registered to handle the requests. The exception can, when it's reporting that the session is expired before even bringing up the application, be a bit of a red herring.
However, there seems to be consensus that the exception occurs in some environments even when the Listener is properly configured in web.xml.
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
I don't see any change in the code that was having this problem so it should remain open for this release.
Use strings (the session IDs) as keys since some servlet containers (...Websphere) don't implements HttpSession.equals() method properly.
Hi
I am facing the problem still. Can you please let me know if I am missing something here.
I am using Icefaces 1.6.1, JBoss Server 4.0, When I request for index.jsp I get.
3: <title>ICEfaces Component Showcase</title>
4: </head>
5: <body>
6: <jsp:forward page="welcomeJSF.iface" />
7: </body>
8: </html>
javax.servlet.ServletException: Session expired
com.icesoft.faces.webapp.http.servlet.MainServlet.service(MainServlet.java:102)
javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Thanks in advance,
Sarat
I am getting the same error with ICEFaces 1.6.2 running on Tomcat 5.5.26.
Assigning to Mircea.
I saw this testing something unrelated on WebSphere. It appears that this logic in SessionDispatcher:
...
if (sessionBoundServers.containsKey(session)) {
...
is always returning false. I put in some logging and it appears that the session it is looking for IS in the map but I guess the equals() logic for Session objects is not reliable and/or container specific. I tried switching over the logic of the SessionDispatcher to rely on session.getId() instead and that did the trick for me.