Thanks for the feedback so far. I actually kept the interactions as simple as
possible exactly to minimize any unknown behaviour. There's no SSL or filters
in the application yet. So my code looks something like the following (by path
of execution, I assume you mean the code's call sequence). So I'm not
forwarding this to any other process, servlet, etc. I even tried downloading a
fresh tomcat 6.0.16 server and doing a clean deploy. I get the same result.
A. is the handling servlet that finds a system facade in the session. Then in
B., that facade does some processing, spits out a response to the printwriter,
and returns. A., then sets the changed facade back into the session and ends.
A.
public void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
...
SystemFacade bsfacade =
(SystemFacade)(req.getSession(true).getAttribute(SystemFacade.FACADE_NAME));
...
bsfacade.perform(req, resp);
req.getSession().setAttribute(FACADE_NAME, bsfacade);
...
}
B.
public synchronized void perform(HttpServletRequest req, HttpServletResponse
resp)
throws ServletException, IOException, InterruptedException {
... do some stuff
PrintWriter pwriter = new PrintWriter(resp.getOutputStream());
pwriter.println(bkell.getPreviousCommandResult().toXML());
pwriter.close();
}
Because this is so simple, I figured I was missing something basic like a
cookie setting in Tomcat. I tried commenting out
req.getSession().setAttribute(FACADE_NAME, bsfacade);, thinking maybe that
nulls out the JSESSIONID. But that has no effect.
Tim
----- Original Message ----
From: Christopher Schultz <[EMAIL PROTECTED]>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Tuesday, April 22, 2008 10:20:25 PM
Subject: Re: Tomcat not sending JSESSIONID (servlet session cookie) with new
sessions
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Len,
Len Popp wrote:
| Have you set cookies="false" in the app's <Context> declaration?
| That'd do it.
That wouldn't explain why Tomcat is adding the cookie to the response,
but the cookie isn't making it across the wire.
Tim, can you tell us a little more about the path of execution? I'm
wondering if you are handling a request, modifying the response, and
then forwarding (on the server side) to another process that maybe
blanks-out the response and effectively kills the cookie or something
like that.
Is there any SSL involved at all? I wouldn't expect the behavior you
describe to result from crossing an SSL boundary (I would expect the
browser to get the cookie, but refuse to send it with the next request).
Are there any special filters or valves that are being applied that
might be modifying the behavior of the response?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgOnOkACgkQ9CaO5/Lv0PBUIQCdH1Q39DcjEM7dm6caLbHLEIrz
PuQAnRuxPKiKx10EnGbV9fyM2ENTLSit
=ULgz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
