Hi Vincent, We are using the JSESSIONID as a session tracking mechanism. We keep the JSESSIONID cookie from the first session that is created, and then associate this cookie with further WebRequests.
The Cactus client code right now makes calls to the ServletTestRedirector, once to call the testXXX method and once to retrieve the result. The beginXXX method allows the user to modify the WebRequest object before the call to the testXXX method on the server. The WebRequest to get the test results does not use the WebRequest that is initialized in the beginXXX method -- it is brand new, and therefore it does not use our JSESSIONID cookie. I would like the WebRequest that is used to get the test results to be same that is initialized in the beginXXX method, although my feature request only specifies that the cookies be added to the WebRequest. The reason is that for each call to get the test results, a new session is created on the Dynamo server, and we currently have a maximum of 20 sessions on our developer licenses. What do you think? Thanks, Charley --- From: Vincent Massol Subject: RE: [patch] Two Cactus feature requests (was RE: Cactus - possible bug) Date: Tue, 16 Jul 2002 15:18:43 -0700 Hi Charles, I was starting to apply your patch WRT setting the cookies in the request when I started to ask myself some question about this ... :-) Could you provide more details ? Certainly it is not about the session cookie (jsessionid) as I don't see how it can relate to the Servlet Config object ? Can you send us the list of cookies that you need to set up when calling a servlet ? Do you always need to set these cookies ? My point is that Cactus need to abide by the Servlet 2.2 and 2.3 spec and I don't see how what it is doing is not conformant to any part of the spec. The 2 HTTP request (run the test, get the result) are completely independent (and are meant to be independent by design). The result of the first request is saved in the application scope (not in the session scope) and thus there doesn't need to be any cookie in the second request. I'm not against applying your patch, but I need more details to understand the rationale. Thanks -Vincent -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
