problems with sessions and servlets

[richard.anderson970]

I'm having a rather perplexing issue that I hope you'll be able to help
me out with. I have an application comprised of a number of servlets
that are meant to be accessed by wireless devices. The issue I'm
having goes as such:

I have 2 servlets: Servlet1 and Servlet2. Users will always access the
application by going through Servlet1. In Servlet1, the service()
method will identify what phone they're using and create a Device
object that should be used session wide for identification of the
device. This done with the following:

request.getSession().setAttribute("device", device);

However, when I access Servlet2, and attempt to get the device object,
like so:

request.getSession().getAttribute("device");

I notice the the object is null. If I print out the session ids at
various stages, the session id in Servlet2 changes from Servlet1. When
I access the same servlets, from a web browser, I notice that the
session ids do not change, and I'm able to access the device object.
Is there something else I should be sending with the phones to maintain
state? I've attempted tacking on ;JSESSIONID=<session id> but this
does nothing. I don't believe there's a way to lookup a session by
session id. Can anyone offer assistance in this matter?

Thanks,
Rich

 

[Ryan Stewart]

I'm having a rather perplexing issue that I hope you'll be able to help
me out with. I have an application comprised of a number of servlets
that are meant to be accessed by wireless devices. The issue I'm
having goes as such:

I have 2 servlets: Servlet1 and Servlet2. Users will always access the
application by going through Servlet1. In Servlet1, the service()
method will identify what phone they're using and create a Device
object that should be used session wide for identification of the
device. This done with the following:

request.getSession().setAttribute("device", device);

However, when I access Servlet2, and attempt to get the device object,
like so:

request.getSession().getAttribute("device");

I notice the the object is null. If I print out the session ids at
various stages, the session id in Servlet2 changes from Servlet1. When
I access the same servlets, from a web browser, I notice that the
session ids do not change, and I'm able to access the device object.
Is there something else I should be sending with the phones to maintain
state? I've attempted tacking on ;JSESSIONID=<session id> but this
does nothing. I don't believe there's a way to lookup a session by
session id. Can anyone offer assistance in this matter?

It seems obvious that whatever device you're using that causes a different
session id does not support cookies, which is how sessions are tracked. Instead
of maually appending the session id, I'd recommend using the encodeURL method of
the response object. That's what it's for. Make sure you're encoding all the
links or use a framework that will do it for you.

 

[richard.anderson970]

It seems obvious that whatever device you're using that causes a different
session id does not support cookies, which is how sessions are tracked. Instead
of maually appending the session id, I'd recommend using the encodeURL method of
the response object. That's what it's for. Make sure you're encoding all the
links or use a framework that will do it for you.

Thanks for the advice! I guess browsers go ahead and do the encoding
for you. I'll give that a shot and let you know the results.

-Rich

 

[John C. Bollinger]

Thanks for the advice! I guess browsers go ahead and do the encoding
for you. I'll give that a shot and let you know the results.

No, browsers have nothing to do with it.
HttpServletResponse.encodeURL() is a means to allow a web application to
support session tracking by URL rewriting, where necessary. The browser
simply uses the URLs specified to it, which contain the session
information if the servlet container determines that they need to do,
and otherwise don't. It is important, if you want to get this right, to
pass _every_ URL referring back to the same web application through
through encodeURL (or encodeRedirectURL, as appropriate).