Can't see any attachment, maybe it was stripped by the apache mail server.
What about the issue of thread safety issue in terms of unsetting a property that's only intended for a *single* invocation? (I mentioned this before on this thread ...) /Eoghan > -----Original Message----- > From: Jarek Gawor [mailto:[EMAIL PROTECTED] > Sent: 14 May 2007 16:03 > To: [email protected] > Cc: [EMAIL PROTECTED] > Subject: Re: Request/ResponseContext of JaxWsClientProxy > > 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > > > How does the RI do it? > > > - Dan > > > > > > On 5/4/07, Daniel Kulp <[EMAIL PROTECTED]> 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 > > > > [EMAIL PROTECTED] > > > > http://www.dankulp.com/blog > > > > > > > > > > > > > > > > -- > > > Dan Diephouse > > > Envoi Solutions > > > http://envoisolutions.com | http://netzooid.com/blog > > > > > >
