Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Session tracking (via session object) Problem

 
Steve Hood
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am attempting to use a session object to store user-entered preferences in an application. I get a reference to a session object in the first of 3 servlets utilized in the app, no problem. I successfully setAttribute(). In a subsequent servlet (#2), I similarly get a reference to the session object created in servlet #1 (verified by getting and displaying session id). I can successfully set and getAttribute(). My problem is in calling servlet #3 (from the HTML form returned to client in servlet #2). When I attempt to get a reference to the existing session object, a new session object is created instead (again, as verified by getting and displaying session id). Subsequently, every attribute value is null when I attempt to retrieve it. I coded another, separate application servlet that I can run at this point (post creation of the new session object) which can successfull get a reference to the original session object, and get the attribute values which servlet #3 cannot. I've simplified servlet #3 so that all it does is simply get the session obj and return it in HTML to the client... it alway gets a new session id, attribute values are null. I'm a student and have tried everything I can to resolve the problem, but I think I may be out of my league. What really concerns me is that none of my instructors have any real insight into the problem. If I don't sound desperate, trust me, I am. Any insight/guidence would be most appreciated. A box of delicious girl scout cookies (without headers!) to anyone who might be able to shed some light!!! Running Tomcat 3.2.1, servlet API 2.2, java 1.3.1 on W2K. Others in the class have no problem. Server config?
Well, thanks... Steve
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13074
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If servlet 1 and 2 can see the session but session 3 can't, I would say that the servlet container considers that servlet 3 is not in the same "web application" as 1 and 2. Are all 3 defined in your web.xml for the application? Are all 3 addressed with the same basic URL? Are you using the "/servlet/" format for any URL?
Bill
 
Kirtikumar Puthran
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Could u give ur code snippets of servlet 2 and servlet 3.
Rgds,
Kirtikumar Puthran
 
David Hibbs
Ranch Hand
Posts: 374
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
William's suggestion seems the most likely. The other possibility is if the session was invalidated for some reason. Look for calls in your code to session.invalidate() to see if you're doing it yourself. Other possibilities might include setting the session expiry time or inactive interval too short, thus allowing the servlet engine to invalidate the session before your request to servlet #3.
 
Steve Hood
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks to you guys and the many others who have taken the time to post responses. After looking at the URL I coded to access each servlet (several times), I found what seems to have been the problem... a slight difference in the path. Namely, in the first two servlets:
"ACTION=http://localhost:8080/....", Whereas in the third "ACTION=http://127.0.0.7:8080/...". Problem solved upon making them all consistant(agh!). I didn't 'see' the problem until Bill prompted me "...Are all 3 addressed with the same basic URL?". As I understand it, localhost is simply an alias for the loopback addr, so if anyone could explain why it doesn't work as I expected, that would be appreciated, but thanks again for all the comments and input. Now, we have Thin Mints, Peanut Butter, Suggared Shortbread...
 
Vikram Prabhu
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The ip for localhost is 127.0.0.1 and not 127.0.0.7 as you might have tried...
 
William Brogden
Author and all-around good cowpoke
Rancher
Posts: 13074
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It didn't work because session IDs are stored according to Cookie rules which do not take aliases into account. Search for RFC 2109 (as I recall) to find the complete rules.
Bill
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic