OK no problem, I'm learning something here too :) I agree, one app cannot access a session created by another app (unless you set singlesignon, which we'll ignore for now).
I am referring just to the single line I quoted earlier, from SRV.7.3 of 2.4 spec. I'm reading that as saying that if app A creates session X for user U, then the user U then accesses app B, which then includes a servlet from app A via its RequestDispatcher as you have done in your example, context A will not have access to the session in the second request, even though it created it, because it was routed through app B, which is not allowed to access it. I might have misinterpreted this, because I have no actual experience of it. I can see that it might be possible that the session is invisible to B but not A. If so I'm more than happy to be told I'm wrong by someone who knows....? > -----Original Message----- > From: Akoulov, Alexandre [IT] > [mailto:[EMAIL PROTECTED] > Sent: Monday 23 May 2005 10:46 > To: Tomcat Users List > Subject: RE: problem: Session invalidation in the servlet > accessed via foreign context > > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
