Hi,
The WorkContext was defined to carry some context such as the conversation
id, http session id and callback path over the thread local. And the usages
are so messy in the code and nobody can really understand how it should be
used.
As part of the final push for clean SPIs, I propose that we remove the
WorkContext and work out a better context propagation story.
There are three cases that involves context propagations:
1) For Invokers on the invocation chain, the context should be exposed by
the Message SPI. We need to add things such as ConverstationID, To and From
to the Message.
2) For an inbound service, the service binding provider (will be responsible
for retrieving the context data from the protocol/transport layer and makes
them available in the Message when it dispatches to the promoted component.
3) Component implementation invokers should be responsible for passing the
context from the incoming Message to the implementation logic and the proxy
or invoker for the references. The propagation should be local to the
component implementation types and we could provide some utilities such as a
ThreadLocal if it helps.
4) For an outbound reference, the reference binding provider should take the
context from the Message and marshal them into the protocol/transport layer.
I did the first cut to remove the WorkContext and use ThreadLocal to pass
the context (used by callback at this moment) and the build is successful
with all modules, samples and itests.
Thoughts?
If there are no objections, I will check them in ASAP and use it as a base
for improvement.
Thanks,
Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
