Ok, you can set first cookie: with setProperty(Heaer_Cookie, ""); and second cookie: with setProperty(Header_Cookie2, "");
back .....(Header_set_Cookie,""); Is it? Tomi -----Urspr�ngliche Nachricht----- Von: Christian Campo [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 8. Juli 2004 13:57 An: [EMAIL PROTECTED] Betreff: Re: accessing HTTP cookies Hi, thanks for trying to sort this out. But setScopedProperty ist a deprecated method (that will be removed soon according to the apiDoc). Also it only sets a local property for that call object. I am looking for a way to supply 2 cookies with 2 different names that are not the standard JSESSIONID name which should then be passed to the webservice. And of course every now and then a Set-Cookie header comes back and I would look to pick it up then and set it in some local var. Still looking for a solution. christian campo ----- Original Message ----- From: Daniel Amadei <[EMAIL PROTECTED]> Date: Thu, 8 Jul 2004 08:21:09 -0300 (ART) Subject: Re: accessing HTTP cookies To: [EMAIL PROTECTED] Hi! I set cookies in the response using the following statement: call.setScopedProperty(HTTPConstants.HEADER_COOKIE, cookie); Maybe there is something similar for getting the request cookie. []'s Daniel Amadei Christian Campo <[EMAIL PROTECTED]> wrote: Hi everyone, I want to use cookies to maintain session state in the client application that I am currently building. However Axis, to hide transport details from the application, I guess does not directly allow to access the cookies that were transported in a call. I am using the dynamic Call Object and do not use generated stubs. On the serverside I found that it is possible to write a global request handle that can "pull" the httpservletrequest object and get the cookie from their. However on the client side the cookie object is very well hidden. The only current solution that we have is accessing private fields using reflection (which of course only works without a SecurityManager). Anybody can help me here ??? BTW: The reason why we choose Cookies and not SOAP Headers is because we use the same mechanism for browser applications and have some central components which are managing and checking the session are not aware of the difference between a webapplication and a webservice. So Cookies is a mechanism that works in both worlds. thanks -- christian campo ________________________________ Yahoo! Mail agora ainda melhor: 100MB, anti-spam e antiv�rus gr�tis! -- christian campo (gmail.com)
