If I remember correctly (I toss out older messages) this was already known because of a null reference to an object bound to the session.
On Fri, 2004-12-10 at 10:21, Phillip Qin wrote: > Yeah, that's my point. > > -----Original Message----- > From: Ben Souther [mailto:[EMAIL PROTECTED] > Sent: December 10, 2004 10:19 AM > To: Tomcat Users List > Subject: RE: How to detect expired session vs. no session? (Solved) > > > I believe it's because they were trying to figure out whether they had a new > session because the old one expired or because they just hit the site for > the first time. In either case the session would be new. > > > > On Fri, 2004-12-10 at 10:11, Phillip Qin wrote: > > I am curious why people spent so much time trying to figure out > > whether > > request.getSession(...) returns null or not but didn't bother using > > request.getSession().isNew()? > > > > > > > > -----Original Message----- > > From: Steve Kirk [mailto:[EMAIL PROTECTED] > > Sent: December 9, 2004 4:36 PM > > To: 'Tomcat Users List' > > Subject: RE: How to detect expired session vs. no session? (Solved) > > > > > > > By default: > > > 1. getSession(true)!=null > > > 2. getSession(false)!=null > > > > > > But if a JSP page contains the tag <%@ page session="false" %>, > > > then: > > > 1. getSession(true)!=null 2. getSession(false)==null > > > > In the last of these 4 cases, do you mean that the implicit JSP > > session object returns null, or that request.getSession(false) returns > > null? I could understand the first behaviour but would be surprised > > by the second. The problem is that it implies that JSPs execute the > > code in a way that is different than if it were included in a servlet, > > and given that JSPs are servlets, this seems puzzling. Again, perhaps > > I'm not fully understanding either your case, or the details of how > > sessions work. > > > > > For my case, sessions will only be created for logged-in users > > > > what is it about your case that makes this happen? I would have > > thought that session creation is independent of whether you are > > authenticating or not. Or is there a way to config TC to not create > > sessions by default, and only create them when the user successfully > > authenticates? > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > !DSPAM:41b9bea273806963321052! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
