You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Jarek Gawor <jg...@gmail.com> on 2007/05/04 20:15:04 UTC
Request/ResponseContext of JaxWsClientProxy
Hi,
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.
Thoughts?
Jarek
Re: Request/ResponseContext of JaxWsClientProxy
Posted by Daniel Kulp <dk...@apache.org>.
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 <jg...@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 <da...@envoisolutions.com> wrote:
> > > How does the RI do it?
> > > - Dan
> > >
> > > On 5/4/07, Daniel Kulp <dk...@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
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Request/ResponseContext of JaxWsClientProxy
Posted by Fred Dushin <fr...@dushin.net>.
Wouldn't this require synchronized blocks around all usage of request
contexts, if proxies were shared across thread instances? Would we
have to write code like:
{{{
// assume p is a reference to a proxy
synchronized (proxy) {
Map<String, Object> requestContext =
((BindingProvider)p).getRequestContext();
p.invoke(...);
}
Map<String, Object> responseContext =
((BindingProvider)p).getResponseContext();
}}}
I'm -1, if that's the case. (Not that I have a vote, or anything...)
-Fred
On May 14, 2007, at 11:03 AM, 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 <jg...@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 <da...@envoisolutions.com> wrote:
>> > How does the RI do it?
>> > - Dan
>> >
>> > On 5/4/07, Daniel Kulp <dk...@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
>> >
>>
Re: Request/ResponseContext of JaxWsClientProxy
Posted by Fred Dushin <fr...@dushin.net>.
I agree.
Is there a process we can start in parallel with your change. I
realize that we are basically taking a stand with the association
between a request context and a proxy (for which I will happily
retract my -1), but I do think it also makes sense to get
clarification on the intended semantics.
-Fred
On May 15, 2007, at 1:28 PM, Jarek Gawor wrote:
>
> Bottom line I think is that the spec needs to be clarified on this
> issue.
Re: Request/ResponseContext of JaxWsClientProxy
Posted by Jarek Gawor <jg...@gmail.com>.
> 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.
Right. That's the exact problem I have ran into. Thanks for explaining
it so clearly :)
Bottom line I think is that the spec needs to be clarified on this
issue. For Dispatch instances the spec is very clear by explicitly
stating that they are not thread safe (section 4.3.1).
Anyway, I just committed this change (same patch as I attached to this
thread before).
Jarek
Re: Request/ResponseContext of JaxWsClientProxy
Posted by Daniel Kulp <dk...@apache.org>.
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:jgawor@gmail.com]
> > Sent: 14 May 2007 16:03
> > To: cxf-dev@incubator.apache.org
> > Cc: dkulp@apache.org
> > 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 <jg...@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 <da...@envoisolutions.com> wrote:
> > > > How does the RI do it?
> > > > - Dan
> > > >
> > > > On 5/4/07, Daniel Kulp <dk...@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
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
RE: Request/ResponseContext of JaxWsClientProxy
Posted by "Glynn, Eoghan" <eo...@iona.com>.
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:jgawor@gmail.com]
> Sent: 14 May 2007 16:03
> To: cxf-dev@incubator.apache.org
> Cc: dkulp@apache.org
> 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 <jg...@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 <da...@envoisolutions.com> wrote:
> > > How does the RI do it?
> > > - Dan
> > >
> > > On 5/4/07, Daniel Kulp <dk...@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
> > >
> >
>
Re: Request/ResponseContext of JaxWsClientProxy
Posted by Jarek Gawor <jg...@gmail.com>.
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 <jg...@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 <da...@envoisolutions.com> wrote:
> > How does the RI do it?
> > - Dan
> >
> > On 5/4/07, Daniel Kulp <dk...@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
> >
>
Re: Request/ResponseContext of JaxWsClientProxy
Posted by Jarek Gawor <jg...@gmail.com>.
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 <da...@envoisolutions.com> wrote:
> How does the RI do it?
> - Dan
>
> On 5/4/07, Daniel Kulp <dk...@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
>
Re: Request/ResponseContext of JaxWsClientProxy
Posted by Dan Diephouse <da...@envoisolutions.com>.
How does the RI do it?
- Dan
On 5/4/07, Daniel Kulp <dk...@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
Re: Request/ResponseContext of JaxWsClientProxy
Posted by Jarek Gawor <jg...@gmail.com>.
In JAX-WS spec 4.2.1 is says "Modifications to the request context
while previously invoked operations are in-progress MUST NOT affect
the contents of the message context for the previously invoked
operations." This could imply that if I do change the request property
it should be applied to all future invocations using the same proxy
instance.
Also, from http://java.sun.com/javase/6/docs/api/javax/xml/ws/BindingProvider.html#getResponseContext()
says about getResponseContext(): "Get the context that resulted from
processing a response message. The returned context is for the most
recently completed synchronous operation. Subsequent synchronous
operation invocations overwrite the response context." This could
indicate that in multiple thread scenario getResponseContext() could
return information about any 'recently completed' call from any
invocation using the same proxy instance.
This is all a bit of a stretch but I'm just trying to understand
what's the right approach from the spec point of view. But either way,
whatever the solution I think this needs to be documented because each
approach has its own issues.
Jarek
On 5/4/07, Daniel Kulp <dk...@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
>
Re: Request/ResponseContext of JaxWsClientProxy
Posted by Daniel Kulp <dk...@apache.org>.
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
RE: Request/ResponseContext of JaxWsClientProxy
Posted by "Glynn, Eoghan" <eo...@iona.com>.
Hi Jarek,
Do you recall this mail from a previous related discussion.
http://mail-archives.apache.org/mod_mbox/incubator-cxf-dev/200704.mbox/%
3cFA1787F64A095C4090E76EBAF8B183E071FD65@emea-ems1.IONAGLOBAL.COM%3e
I agree that the pre-proxy approach would seem to be more logical, but
there would be a thread-safety issue around how to unset request context
properties that really should only apply to a *single* invocation (e.g.
an application-supplied WS-A message ID), if another invocation could
kick off concurrently on another thread before the initial invocation
complete.
/Eoghan
> -----Original Message-----
> From: Jarek Gawor [mailto:jgawor@gmail.com]
> Sent: 04 May 2007 19:15
> To: cxf-dev@incubator.apache.org
> Subject: Request/ResponseContext of JaxWsClientProxy
>
> Hi,
>
> 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.
>
> Thoughts?
>
> Jarek
>