Simon Laws wrote:
On Mon, Feb 7, 2011 at 10:35 AM, Simon Nash <n...@apache.org> wrote:
Simon Laws wrote:
On Fri, Feb 4, 2011 at 4:49 PM, Yang, Gang CTR US USA
<gang.y...@us.army.mil> wrote:
(cut)
To reply to both Simon and Gangs posts...
I had missed that. I don't know why we put the request message in the
TMC rather than leaving it as is. It's not clear to me what's pulling
the request message from there at the moment. All of the interceptors
down the chain already have access to the request message part of the
invoke. There must be a reason so I'll have to look more closely.
It's because the application code needs access to information in the
inbound Message object. This includes for example the callback endpoint and
also the service reference returned by RequestContext.getServiceReference().
The Message object isn't passed in to the application code, so it can
only be obtained from the ThreadMessageContext.
Simon
I agree with Simon that we would have to be careful before just
copying headers arbitrarily from one to another. I had thought this
was the job of policy handlers on the reference side.
Simon
What do you mean by "the application code" here. The context switch we
are talking about is on the reference side.
Simon
OK, I understand your point now. Interestingly I had a very similar
thought when thinking some more about the "invocation context" concept
(see my other recent post). We could make the lifecycles of "message context"
and "invocation context" the same by deferring/avoiding the message context
switch on the reference side. The message context switch would still be
needed on the service side.
Simon
