0

I have a web application that has a phase listener. When the phase listener runs, it does a few things with the session map. Randomly (usually not the firs request, but more frequently when requests are issued quickly) I am getting a null pointer exception from SessionMap.put. After a bit of digging it appeared that when SessionMap.put was getting the session, it was getting back a null pointer (even though it calls getSession(true)). So I did a bit of debugging and discovered that indeed getSession and getRequestedSessionId are both returning null when invoked. However, if you check the cookies in the request (request.getCookies()) the JSESSIONID cookie is included in the request and has the correct session. There doesn't seem to be rhyme or reason as to why the session and the requested session id some times comes back normal and sometimes comes back null. The only other piece of information that might be relevant here is that the JSF pages are living within the same application that some older JSP/Servlets are living in.

I've looked around online and others have said setting the cookie path to "/" has solved similar issues for them, but it doesn't appear to solve the issue here.

moneyt
  • 442
  • 8
  • 18
  • To exclude one and other, try a different server make/version. – BalusC Feb 28 '12 at 21:56
  • Sorry, I'm not quite sure what you mean here. Try a different version of Tomcat? Or a different version of Mojarra? Or just another server running tomcat 7? – moneyt Feb 28 '12 at 22:08
  • Tomcat is a server. Try different Tomcat version. Or a different server make (e.g. Glassfish, JBoss AS, Jetty, etc). – BalusC Feb 28 '12 at 22:44
  • The issue persists on other releases of Tomcat 7, but does not appear to occur in tomcat 6. The two Tomcats are configured identically. The only difference is that for some reason, when Tomcat 7 starts, it's throwing a class not found exception for the class GetoptDemo, though from what little I can find about this class online, that doesn't appear like it should be related. – moneyt Feb 29 '12 at 15:29
  • Sounds like a dirty classpath. Make sure that you haven't ever added arbitrary JARs to the JRE's `/lib` or `/lib/ext` or the server's own `/lib` folder. Most starters do that to circumvent `javac` compile errors, but that's actually the wrong way. – BalusC Feb 29 '12 at 15:37
  • The only JAR we've added to the Tomcat /lib folder is a jdbc driver for postgres. All the other jars we need are on the application's build path. We've used the same postgres jdbc jar in the tomcat lib folder throughout this application's previous life on Tomcat 6, and on a current application already installed on Tomcat 7 without issue. – moneyt Feb 29 '12 at 15:54
  • Hotspot 1.6.0_26-b03, working and testing in eclipse with a tomcat 7.0.22 install – moneyt Feb 29 '12 at 16:02
  • I don't know. I also use Oracle JDK 1.6/1.7 and Apache Tomcat 6/7 all the time on local dev, I've never seen this. That it works on Tomcat 6 indicates an environmental problem related to Tomcat 7. It's at least not a JSF problem. – BalusC Feb 29 '12 at 16:04
  • Apparently, the issue was a stale request being in the beans that I was injecting into the phase listener that I asked about here (http://stackoverflow.com/questions/9473404/accessing-managed-beans-inside-a-restore-view-phase-listener). Though these beans were request scoped,it appears they weren't always destroyed at the end of the request, and on the next request, the bean in the listener would be an old copy rather than a new one with a new request. The issue appears to be fixed by instantiating the bean I need manually, and not holding onto the request. Is there a better way to do this? – moneyt Feb 29 '12 at 17:01
  • Do you mean to say that you've assigned the `HttpServletRequest` as an instance variable of the `PhaseListener`? This is definitely bad design which makes your code not threadsafe. See for background information about servlets and threadsafety also http://stackoverflow.com/questions/3106452/how-do-servlets-work-instantiation-session-variables-and-multithreading/3106909#3106909 – BalusC Feb 29 '12 at 17:08
  • It was an instance variable of the request scoped bean, which was a managed property in the PhaseListener, which I guess is enough to keep it around between requests. It also explains why I never ran into this before as this is the first PhaseListener I've used. Is it even thread safe to make beans managed properties of PhaseListeners or should I always get them via the code in the previously linked question if I need to access one in a PhaseListener? – moneyt Feb 29 '12 at 17:23
  • There is only one instance of the `PhaseListener` throughout application's lifetime. You should definitely not assign request or session scoped data as an instance variable of it. This is a huge bug. Just work with it in the method local scope. – BalusC Feb 29 '12 at 17:29

0 Answers0