It's a "feature" of the Servlet specification if you will...actually it's somewhat of an accident of nature, given the way browsers are specified to work WRT cookies.
- Cookies are (in the world of Web browsers) inherently server-name based. so if you get a cookie from "www.yahoo.com" you will send that cookie on each subsequent request to "www.yahoo.com" -- and further, you will __only__ send it to "www.yahoo.com", or anything under that domain (meaning "xxx.www.yahoo.com" also gets this cookie from you). Also, if you get a cookie from "yahoo.com" then you will send that cookie to ANY site with the pattern *.yahoo.com. - Contexts under the servlet specification are based on the first / after the site name. So "www.mysite.com/foobar" and "www.mysite.com/jimmy" are two different applications, with two different hash tables for their session objects. They "can't" know about each other -- this is a security and configuration feature -- see the servlet specification. So -- do "all" appservers behave this way? Yes and no. I will tell you that all appservers whose basis for distinguishing applications is like the Servlet specification's -- based on top-level virtual path -- then, yes, without some special hacking or customization, the app server will behave this way (unless they specifically tell you otherwise, in other words). So it's not just a "Tomcat" thing. You might consider instead of your current scheme to use virtual hosts. Instead of "www.mysite.com/app1" and "www.mysite.com/app2" you could have "app1.mysite.com" and "app2.mysite.com" as one way of working around this "feature." cheers fillup On 5/28/02 4:43 PM, "Ghanshyam Patel" <[EMAIL PROTECTED]> wrote: > > Thanks. Are all appservers required to behave this way or is this a Tomcat > feature? > > > -----Original Message----- > From: Phillip Morelock [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 28, 2002 4:33 PM > To: Tomcat Users List > Subject: Re: Cannot retrieve session after visiting a different servlet > contex t > > > This is happening because browsers associate cookies with the name of the > server, whereas Session ID's among tomcat contexts do not cross over. > > Since the cookie / identifier for the session is something like JSESSIONID > and is associated in the client browser with your server, this property gets > overwritten when you visit the other context, because TC will not recognize > your JSESSIONID as belonging to this context. It will assume you have an > expired session and generate a new one. When you go back to the other > context, then of course this happens again, because THAT context won't be > expecting your new JSESSIONID. > > fillup > > > On 5/28/02 4:20 PM, "Ghanshyam Patel" <[EMAIL PROTECTED]> wrote: > >> >> I am using Tomcat 4.0.3 and have 2 servlet contexts running in the same > JVM. >> >> Session SA is created when I visit a page served by servlet context A. >> Session SB is created when I visit a page served by servlet context B. > Now, >> when I revisit a page served by context A, a new session is created! I > would >> expect to find session SA instead of a new session. Is this normal? Why is >> this happening? >> >> Thanks >> Ghanshyam >> >> -- >> To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> >> For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> >> > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
