On Monday 14 May 2007 12:54, Glynn, Eoghan wrote: > 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 ...)
After looking through a bunch of use cases/test cases, I really think in this situation it will have to be up to the user to either: 1) make sure the proxy is used in a synchronized block or 2) make sure they use unique proxy instances on different threads. The main use case that I'm seeing a LOT of (and works with the RI) is that when an application starts up, they create the Proxies (possibly multi proxies that are stored in a proxy pool of some sort) and configure the various attributes like ENDPOINT_URL, SESSION_MAINTAIN, etc... Once configured, the proxies are stored and then used later. The later use can occur on any thread. With the current setup, all the stuff that was pre-configured is lost. Thus, the applications don't work with CXF. From my standpoint, that's the use case that needs to work with CXF. Dan > /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 -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727 C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
