Hi Thomas, didn't know that. However that is still not the solution for me. First I am not using the standard JSESSIONID cookie because thats already taken in another context. Second I have two cookies in fact. So I receive: ssoid=#ss054593485934853495345; Path=/ plid=#pl494593453454534545;Path=/ and possibly also a JSESSIONID (but I don't need to worry about that for the moment) So how can I get and set my ssoid and plid cookie ? regards christian
On Thu, 8 Jul 2004 09:41:52 +0200 , Dorner Thomas <[EMAIL PROTECTED]> wrote: > Hi christian, > > to put the JSession (Cookie: JSESSIONID=5222FBDEB2E63F0A64187E28358BCF37; > Path=/soap) > You can use the constant fields (look in AXIS API Doc). > > When you get the Session, it looks like this: > JSESSIONID=5222FBDEB2E63F0A64187E28358BCF37! > > To put the JSession: > call.setProperty(HTTPConstants.HEADER_COOKIE, session + "; Path=/soap"); > > To get the JSession: > MessageContext context = call.getMessageContext(); > String jSession = (String)context.getProperty(HTTPConstants.HEADER_COOKIE); > > Have Fun Tomi > > -----Urspr�ngliche Nachricht----- > Von: Christian Campo [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 8. Juli 2004 09:34 > An: [EMAIL PROTECTED] > Betreff: accessing HTTP cookies > > 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 > -- christian campo (gmail.com)
