Hi Nan et al,
I'm away from the office for a couple days, but wanted to give an idea
here. I definitely understand the problem better -- you need a way for
the handler to know which client the request has come from, yes? I think
with the SI there is a 1 to 1 mapping of client to handler chain, but
that doesn't mean the same mapping applies to handlers themselves, and
other implementations could do it differently...
The simple fix is to use http header session id across calls and set the
session maintain property on the client. Of course, if you don't have
access to the service, you can't make that change! Here's an idea that
might help, but I can't test it now and don't know if it will work or
not. You can give it a shot or I may try it later in the week -- anyway,
I wanted to put it out there for you.
Set the session maintain property on the stub as if the session id were
coming back in the http header (not soap header). In your client
handler, you get your token id out of the soap header in
handleResponse(). From the SOAPMessage object, get the mime headers and
add a session id header. I don't have the javadocs handy for the method
names, but if you check the jwsdp javadocs for SOAPMessage you should
see the calls. That might work in that the client will now remember that
http "cookie" and set it in the mime headers again when it makes the
next request. Then your handler can read it back out of the MimeHeaders
object during the request and set it in the SOAPHeader. Again, until I
can test it or look at the code in detail I'm not sure if that will
work, but I wanted to get the idea to you sooner than later.
I will also check with the spec lead on the idea to see if it has been
considered.
Cheers,
Bobby
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net