Okay... maybe i missed something here.
Here is my situation:
I have a single web service, the login call to the web service returns a token in the response header,
and the subsequent calls to the web service, the client needs to pass the token back in the request
header as an valid identification. So token is session specific, meaning different client session
need to hold on to a different token/id.
My web service client is a jsp, and the get/set token is done completely in a client soap handler
because i cannot found other ways of doing it in jaxrpc. When 2 browser client is interacting
with web serivce at the same time via my jsp web service client, the soap handler need to use a
session specific token holder to get/set token, the singleton class has only one instance per jvm,
the token kept for a browser client will be overwritten by the second browser client.
Thats why i'm now using a ThreadLocal variable as the client token holder.
Does this make sense?
Nan
> -----Original Message-----
> From: Jeremy Suriel [mailto:jeremy.suriel_at_eassist.com]
> Sent: Friday, October 24, 2003 12:51 PM
> To: 'users_at_jax-rpc.dev.java.net'
> Subject: RE: Re: MessageContext->Stub and Stub->MessageContext?
>
>
> I'm not sure I agree with you Nan. The singleton approach does work
> (remember, this handler will be on the clientside). In fact,
> I have it
> working with a webservice client communication with multiple
> web services
> hosted on the same web server using the same http session
> (Something that
> session_maintain property will not do for you). As well, the
> http headers
> are accessible via the handlers and messagecontext.
>
> -----Original Message-----
> From: Nan Xiong [mailto:Nan.Xiong_at_viewstar.com]
> Sent: Friday, October 24, 2003 12:41 PM
> To: users_at_jax-rpc.dev.java.net
> Subject: RE: Re: MessageContext->Stub and Stub->MessageContext?
>
> Bobby,
> see my reply inline below...
>
> > -----Original Message-----
> > From: Bobby Bissett - Javasoft [mailto:robert.bissett_at_sun.com]
> > Sent: Friday, October 24, 2003 11:14 AM
> > To: users_at_jax-rpc.dev.java.net
> > Subject: Re: MessageContext->Stub and Stub->MessageContext?
> >
> >
> > > Your suggestion of using singleton class for save/retrieve
> > token works for simple java client, what if
> > > the client is a web client?
> >
> > I'm not sure I understand this question -- the case I was
> > talking about
> > was a web client, and it was just a simple way that
> handlers and the
> > client app can share information.
>
> singleton does not work for a client that runs in a
> multi-thread enviornment
> because
> the tokens need to be maintained for different http sessions.
> i now figured
> out using
> ThreadLocal as the token holder in my jsp web service client,
> but I dont
> know
> whether it is too much a hack?!
>
> >
> > > Do you have a suggestion on how to access HttpSession from
> > a client soap
> > > handler???
> >
> > The jaxrpc runtime takes care of handling the http work for
> > you, so you
> > can't access info in the http header (as opposed to SOAP
> > header) in your
> > client. If you want your client to maintain session using the http
> > header session id, you don't have to do any work in the
> > client for this.
> > Just set the SESSION_MAINTAIN_PROPERTY on your stub before
> making rpc
> > requests.
>
> I was trying to find out a way to stash the session specific token on
> the httpsession, but could not figure out a way to access httpsession
> from a soap handler. My feeling is that soap handler only
> allow to access
> MessageContext, which is pretty limited when wanting to share data for
> handlers
> btwn different soap calls.
>
> >
> > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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