1
votes

I have a legacy Java 1.6 running localhost with Tomcat 7 application using JSP pages, a frameset with frames, javascript, but no framework like Struts. I pass an object to display in the page from the servlet using the request or session and that works fine.

However, I made some changes recently and now I can't retrieve that same object back from the session or request. It had been working fine previously, so I'm not sure what is broken, but I can't even send a string value back from the JSP's back to the servlet.

I created a new stripped down JSP and I can't get anything back from that either using the request or session. It does the same thing when I push the code our Tomcat 6 web server. Using the debugger, I see the objects populated in the session, but then lost later when a new session is created each time as in using this simple code to get the sessionid:

System.out.println("The session id is: " + session.getId());

The session id is: EB431C19B41957B2BB2EFC3DBAF32241

The session id is: C9CBD30E84D5C93DF6114C1412AE5523 I then see this in firebug under the Header, response headers:

Set-Cookie JSESSIONID=C9CBD30E84D5C93DF6114C1412AE5523; Path=/Name omitted here/; HttpOnly,

so I know cookies are set. I also removed jquery and I"m stripping down the jsp code as much as possible, but that doesn't seem to be the issue.

I'm using: HttpSession session = request.getSession(true); but using false didn't matter.

session.setAttribute("ObjNameList", objNameList);

The context.xml has cookies set to true and we do use response.sendRedirect, but only if an error is thrown as in: response.sendRedirect("Error.jsp"); There is no place in the code with session invalidate either.

All I'm doing from the jsp is sending a form back using something like:

document.formName.submit(); which works fine. Using this code to try and set a simple string in the session doesn't work either:

session.setAttribute("somevalue","someValue");

Gives me null in the servlet here:

String val = (String) session.getAttribute("somevalue");

Any ideas as to what could be causing this?

Resultion:

It turned out to be an issue with the url, a typo actually, as BalusC mentioned, so the path for the session cookies didn't match between the jsp and the servlet.

1
Session cookies are tied to specific domain+path. Just open up the HTTP traffic monitor in webbrowser's developer toolset and track cookie traffic.BalusC
I had firebug and live http headers. I just added httpfox to use for monitoring. Is this what you were thinking of?James Drinkard
Yes, check there if cookies behave as per expectations.BalusC
You observed that the server has set the cookies. But did the client return them in the subsequent request too? Check the Cookie header. If this is absent, then apparently the cookie domain+path which were set in Set-Cookie header didn't match that of the request on which the Cookie header needed to be set. Have you modified the session cookie path in Tomcat or web.xml configuration or so? "Name omitted here" looks strange as it usually just represents the context path.BalusC
No, the session is null when the request comes back from the jsp in the servlet. I'll check the cookie header. I don't have anything set for session cookies, except in the context.xml to cookies="true". Name omitted here means I don't want to put the actual context path. No, I haven't modified the web.xmlJames Drinkard

1 Answers

1
votes

Doublecheck if the request URL to that servlet matches the session cookie domain and path. If it doesn't match, then the browser simply won't send the session cookie back along with the request and the server will think that there's no means of an established session and will therefore simply create a new one.

You can check cookies in the HTTP traffic monitor of browser's web developer toolset (press F12 in Chrome/Firefox23+/IE9+ and open "Network" tab). When a new session starts, the server must have returned a response with Set-Cookie header with therein the cookie value and path (and implicitly domain). When the browser sends a subsequent request on the same domain and path, then it must have passed that cookie back via Cookie request header.

See also: