| Summary: | session listener invalidate session | ||
|---|---|---|---|
| Product: | Tomcat 7 | Reporter: | Soner Sivri <sivrisoner> |
| Component: | Servlet & JSP API | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | ||
| Priority: | P2 | ||
| Version: | 7.0.47 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
Why would you call session.invalidate() from SessionListener.sessionDestroyed? It's already in the process of being invalidated. The code is old code My Friend who wrote the code said there was A problem why he put it. He did not remember the problem. I understood that you said remove session.invalidate() There should be no need to call session.invalidate() from the session destroyed event. However, entering an infinite loop if application code does do this is far from ideal. This is a side-effect of the fix for bug 55521. I'll look into a fix. This has been fixed in 8.0.x for 8.0.6 onwards and in 7.0.x 7.0.54 onwards. |
we have sessionlistener in sessionDestroyed method we call session.invalidate() in version 7.0.42 its ok but newer versions loops code public void sessionDestroyed(HttpSessionEvent arg0) { if(arg0 !=null && arg0.getSession() !=null) { HttpSession session = arg0.getSession(); String sessionId = session.getId(); if(sessionId != null) { UserPrincipal userPrincipal = (UserPrincipal)session.getAttribute(ContextVar.USERPRINCIPLE); if (userPrincipal != null) { UserOpBLO userOpBLO = new UserOpBLO(new ResourcePool()); userOpBLO.processLogoutActivity(sessionId, userPrincipal.getUserId()); CurrentSessions.SESSIONS.remove(sessionId); session.invalidate(); } } } }