RE: problem: Session invalidation in the servlet accessed via foreign context
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 no
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: Mond
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 i
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. ses
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 conte
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 gr
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]
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]
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]
