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/