Thanks, Steve, again. >That's what I'm >reading the servlet 2.4 spec as saying, because you can't invalidate a >session in one context that is not accessible to you in another context, >irrespective of whether you use getRequestDispatcher to do that.
What section of the spec defines such behaviour? I understand that we cannot access a session created by one application from another one. However, an application can manage its own session(s) and the way the application is accessed (via RequestDispatcher or via direct hit) should not affect session management at all. Thanks again, I really appreciate your thoughts on this matter. Kind regards, Alex. -----Original Message----- From: Steve Kirk [mailto:[EMAIL PROTECTED] Sent: Monday, 23 May 2005 6:21 PM To: 'Tomcat Users List' Subject: RE: problem: Session invalidation in the servlet accessed via foreign context OK. So... your conclusion is that you can't do that, right? That's what I'm reading the servlet 2.4 spec as saying, because you can't invalidate a session in one context that is not accessible to you in another context, irrespective of whether you use getRequestDispatcher to do that. Or maybe I'm reading it wrong. That's possible as to be honest I've never tried what you're trying for real, I'm going on what the docs say not personal experience. > -----Original Message----- > From: Akoulov, Alexandre [IT] > [mailto:[EMAIL PROTECTED] > Sent: Monday 23 May 2005 06:53 > To: Tomcat Users List > Subject: RE: problem: Session invalidation in the servlet > accessed via foreign context > > > Thanks again, Steve, for your time. > > I am not trying to share sessions between different apps. I > just want to ensure that when we're programmatically > accessing web application in the different context it can do > its own session management (ie invalidate / create new ones) > > -----Original Message----- > From: Steve Kirk [mailto:[EMAIL PROTECTED] > Sent: Monday, 23 May 2005 11:52 AM > To: 'Tomcat Users List' > Subject: RE: problem: Session invalidation in the servlet accessed via > foreign context > > > > I'm not sure why you think there is a problem with > invalidation. I'm no > expert, but I'm not sure that I would expect the code below > to work, because > by default, servlets must not share sessions between webapps, > and you are > asking that a client request to one context is passed to > another, and still > the session data is available. Withouht single sign-on, I would have > thought that sessions will not be shared. > > I've just flipped through the 2.4 servlet spec. Section SRV.7.3 says > something very specific about your scenario, as follows: "if > a servlet uses > the RequestDispatcher to call a servlet in another Web > application, any > sessions created for and visible to the servlet being called must be > different from those visible to the calling servlet." > > I appreciate that you are also saying that v3/v4 behaved > differently - but > are you sure that the config of those versions was not > different, perhaps > they were configured to share sessions (single sign-on)? I'm > not sure on > the detail of earlier versions of the servlet spec, but > perhaps session > behaviour was defined differently in previous versions. You > could find out > with a google search, or maybe someone else will answer.... > > > -----Original Message----- > > From: Akoulov, Alexandre [IT] > > [mailto:[EMAIL PROTECTED] > > Sent: Monday 23 May 2005 01:29 > > To: Tomcat Users List > > Subject: RE: problem: Session invalidation in the servlet > > accessed via foreign context > > > > > > Thanks a lot, Steve, for your reply. > > > > No, I am not using SingleSignOn neither hoping to share the > > same session across contexts. > > > > The only thing I was testing is that I could invalidate and > > then create a new session in different scenarios. > > > > I ran the test with the java debugger and could observe that > > when invalidating/creating a session in ForeignContextServlet > > it in fact did not create a new session and left us with the > > reference to old (ie invalidated) session after line No.3. > > > > My next step is start looking into the tomcat source code to > > try to work out what's happening. Do you think it's best way > > to approach this issue? > > > > > > Thanks again, > > > > Alex. > > > > -----Original Message----- > > From: Steve Kirk [mailto:[EMAIL PROTECTED] > > Sent: Monday, 23 May 2005 10:18 AM > > To: 'Tomcat Users List' > > Subject: RE: problem: Session invalidation in the servlet > accessed via > > foreign context > > > > > > > > I'm not sure I fully understand this issue, but seeing as > > no-one else seems > > to have replied yet, maybe a few Qs might help you work through it: > > > > Are you hoping that both contexts will share their sessions? > > > > Are you using the SingleSignOn feature in server.xml? > > > > When you say that ForeignContextServlet does not create a > new session > > object, are you explicitly testing that within > > ForeignContextServlet itself, > > or from a servlet in another context (e.g. > DebuggerServlet)? i.e. is > > null==session after step 3? > > > > You say that the session is invalid/null after line 2, but > > have you tested > > that it was valid/non-null before line 2? > > > > > -----Original Message----- > > > From: Akoulov, Alexandre [IT] > > > [mailto:[EMAIL PROTECTED] > > > Sent: Monday 23 May 2005 00:43 > > > To: tomcat-user@jakarta.apache.org > > > Subject: Re: problem: Session invalidation in the servlet > > > accessed via foreign context > > > > > > > > > Hi all, > > > > > > I'd greatly appreciate if you could shed a ray of light on > > > the following problem ( see below) > > > > > > > > > > > > -----Original Message----- > > > From: Akoulov, Alexandre [IT] > > > Sent: Friday, 20 May 2005 11:15 AM > > > To: Tomcat Users List > > > Subject: problem: Session invalidation in the servlet accessed via > > > foreign context > > > > > > > > > Hi all, > > > > > > It seems that there is a problem with session invalidation in > > > tomcat5.0. Please refer to the explanation below: > > > > > > > > > 1. HttpSession session = req.getSession(true); // get > > > existing user session or create one if does not exist > > > 2. session.invalidate(); // invalidate user session > > > > > 3. session = req.getSession(true); // create a new session ( > > > ie a valid session) > > > > > > The above three lines of code are commonly used to invalidate > > > the user session and then create a new one. Tomcat implements > > > this behaviour by creating a new session object in line No.3. > > > However, in tomcat5.0 implementation (5.0.28) when the above > > > code is accessed via foreign context it does not create a new > > > session object and therefore a session is still invalid after > > > lineNo.3 is executed. The following code demonstrates the > > > problem: > > > > > > > > > // servlet that runs in the same tomcat instance but in a > > > different context to DebuggerServlet's context > > > public class ForeignContextServlet extends HttpServlet { > > > public void doGet(HttpServletRequest req, > > > HttpServletResponse res) > > > throws ServletException, IOException { > > > > > > HttpSession session = req.getSession(true); > > > > > > session.invalidate(); > > > session = req.getSession(true); // > > > !!!!!!PROBLEM!!!!!!!!!! does NOT create a new session when > > > accessed via foreign context's dispatcher > > > } > > > } > > > > > > > > > // servlet that accesses ForeignContextServlet via foreign > > > context's dispatcher > > > public class DebuggerServlet extends HttpServlet { > > > public void doGet(HttpServletRequest req, > > > HttpServletResponse res) > > > throws ServletException, IOException { > > > > > > ServletContext ctx = getServletContext(); > > > > > > // dispatch the request to the servlet in a > > different context > > > ServletContext foreignContext = > > > ctx.getContext("/AccessCommon"); > > > > > > foreignContext.getRequestDispatcher("/foreignContextServlet"). > > > include(req, res); > > > } > > > } > > > > > > Such behaviour is only observed in tomcat 5.0 (have not tried > > > on tomcat5.5); tomcat3 and tomcat4 do create new session > > > objects in lineNo.3 > > > > > > > > > I greatly appreciate your comments on this issue. > > > > > > > > > Kind regards, > > > > > > Alex. > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > 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] > > > > > > > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- 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]
