Ok, I see. I deliberately decided to not include "async" in the name since it is really a "single request/response
processing context" - e.g. we may ultimately find another use for it.
...but I don't insist on this name, although I find it ok.
Marek.
On 09/22/2011 11:32 AM, Sergey Beryozkin wrote:
> Hi,
> On 21/09/11 16:41, Marek Potociar wrote:
>> Hi Sergey,
>> not sure I understand. Can you please elaborate?
>>
>
> My understanding that ExecutionContext, as a new name for AsyncContext, is supposed to represent the context associated
> with the async invocation. When I say write a client filter dealing with the sync invocation, I think the filter is
> working on something associated with the current execution context, we have a current invocation and a given in
> parameter is a property of that execution context. This is just the way I see it, so what I really meant is that
> ExecutionContext is not very specific to the async invocations in my own mind at least
> It's a good name though :-)
> thanks, Sergey
>
>> Marek
>>
>> On 09/21/2011 03:48 PM, Sergey Beryozkin wrote:
>>> Hi Marek - may be that can interfere with any future enhancements to do with representing the current execution context,
>>> which exists even for sync services...Just a thought,
>>>
>>> Cheers, Sergey
>>> On 21/09/11 11:16, Marek Potociar wrote:
>>>> This was done to avoid the confusion with Servlet 3.x API. Let me know if you have any issues with that change.
>>>>
>>>> Thank you,
>>>> Marek
>>>