cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor" <jga...@gmail.com>
Subject Re: Request/ResponseContext of JaxWsClientProxy
Date Mon, 14 May 2007 15:03:26 GMT
Based on all the info we have on this issue I propose the following
change (patch attached). Basically, make the request context to be
associated with the instance and leave the response context as is
(associated with the thread).

What do people think?

Jarek

On 5/10/07, Jarek Gawor <jgawor@gmail.com> wrote:
> I talked to some Sun JAX-WS RI developers today at JavaOne and
> although they were not 100% sure about this issue they were pretty
> sure the request/response context properties are associated with the
> proxy instance.
>
> Jarek
>
> On 5/5/07, Dan Diephouse <dan@envoisolutions.com> wrote:
> > How does the RI do it?
> > - Dan
> >
> > On 5/4/07, Daniel Kulp <dkulp@apache.org> wrote:
> > >
> > >
> > > On Friday 04 May 2007 14:15, Jarek Gawor wrote:
> > > > I have noticed that the RequestContext and ResponseContext of
> > > > JaxWsClientProxy is associated with the thread and not the instance of
> > > > the proxy. My understanding is that it should be associated with the
> > > > instance but I can't find any specific documentation on this issue in
> > > > the specs.
> > >
> > > I was afraid this issue was going to come up.  :-(
> > >
> > > Basically, there isn't a way to make the proxies thread safe without
> > > making them ThreadLocals.   The main problem this causes is that one
> > > thread cannot configure a global proxy that is then used on other
> > > threads.   The configuration is lost.
> > >
> > > The ResponseContext really needs to be ThreadLocal.   It's the context
> > > information for the last request.  If you have two threads making
> > > requests, if it wasn't local, you'd have no idea what the response
> > > correlated too.
> > >
> > > For the request, there are a few options:
> > > 1) Keep it thread local - this is thread safe, but has the config issues.
> > > 2) Have a "default" one that is used until the first invoke on a thread.
> > > It then gets copied to the ThreadLocal.
> > > 3) Make it non-local - this has other concurrency issues.
> > >
> > > Definitely something I'll need to noodle on a bit more to figure out all
> > > the ramifications of the various options.
> > >
> > > --
> > > J. Daniel Kulp
> > > Principal Engineer
> > > IONA
> > > P: 781-902-8727    C: 508-380-7194
> > > daniel.kulp@iona.com
> > > http://www.dankulp.com/blog
> > >
> >
> >
> >
> > --
> > Dan Diephouse
> > Envoi Solutions
> > http://envoisolutions.com | http://netzooid.com/blog
> >
>

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message