Sorry Bobby I cannot seem to let this thread die :) Well, I have experienced some problem with
ThreadLocal implementation I talked about in handling passing session token in soap header btwn
soap calls. I runs my web service client in Tomcat, since tomcat keeps thread pool i cannot assume
all requests for a jsp session are serverd by threads created from one single parent thread.
Basically, your statement of "just a matter of storing some data in a multithreaded environment"
may not be very practical in a j2ee server. I hope you agree with my assessment. I hope jaxrpc
standard can include a solution for this senario. Our service is a .NET service and already in
production, so it is not possible to change the service to explicitly pass the token as
operation arguments, .NET client can handle this very easily. in java world, we are using Axis for
at this moment, and Axis allow to access a session specific object from its implementation of
MessageContext, but I very much looking forward to a jaxrpc standard solution.
Thanks
Nan
> -----Original Message-----
> From: Nan Xiong
> Sent: Friday, October 24, 2003 1:40 PM
> To: users_at_jax-rpc.dev.java.net
> Subject: RE: Re: MessageContext->Stub and Stub->MessageContext?
>
>
>
>
> > -----Original Message-----
> > From: Bobby Bissett - Javasoft [mailto:robert.bissett_at_sun.com]
> > Sent: Friday, October 24, 2003 1:19 PM
> > To: users_at_jax-rpc.dev.java.net
> > Subject: Re: MessageContext->Stub and Stub->MessageContext?
> >
> >
> > Nan Xiong wrote:
> > > 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,
> > [...]
> >
> > By "response header", do you mean the http response header, or the
> > header of the SOAPMessage response?
>
> SOAP response header.
>
> >
> > If the former, did you try setting the session maintain
> > property on the
> > stub? If the latter, then this is just a matter of storing
> > some data in
> > a multithreaded environment and not really a jaxrpc problem
> > specifically, right (but still a good architectural question)?
> >
>
> i guess you can put it that way. however, if jaxrpc allow acessing
> the associated stub/call object from messagecontext in a soap
> handler, then
> stub/call object can acts like a good session specific holder
> - it is far lot
> more cleanner than using a ThreadLocal from soap handler.
> Using ThreadLocal
> in a web container, I'm really concerned about i dont have control
> of web container's threading model.
>
> > 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