axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Campo <>
Subject Re: AW: accessing HTTP cookies
Date Thu, 08 Jul 2004 07:56:54 GMT
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=/
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 ?

On Thu, 8 Jul 2004 09:41:52 +0200 , Dorner Thomas
<> 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 []
> Gesendet: Donnerstag, 8. Juli 2004 09:34
> An:
> 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 (

View raw message