I'm ok with that. Dan
On Monday 14 May 2007 11:03, Jarek Gawor wrote: > 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 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
