On 01/12/11 16:04, Marek Potociar wrote:
>
>
> On 12/01/2011 04:55 PM, Sergey Beryozkin wrote:
>> On 01/12/11 14:57, Marek Potociar wrote:
>>>
>>>
>>> On 11/30/2011 04:10 PM, Sergey Beryozkin wrote:
>>>> On 30/11/11 13:12, Bill Burke wrote:
>>>>>
>>>>>
>>>>> On 11/29/11 11:58 AM, Sergey Beryozkin wrote:
>>>>>> Next the only other case I can see us needing to address in the future
>>>>>> versions of the spec is support for the suspended invocations.
>>>>>> I'd do
>>>>>>
>>>>>
>>>>> I don't see why you'd need support for suspended invocations within the
>>>>> filter api. Especially when you have suspend methods within
>>>>> ExecutionContext.
>>>>>
>>>> That is my concern too, a filter updates or blocks the request and keeping the filter spec as simple as possible is a
>>>> way to go IMHO as opposed to designing the filter api around something that will allow the filters assume the role of
>>>> endpoints doing the actual job...And even if filters will do be able to do then it would need to be managed internally,
>>>> possibly with the help of FilterContext
>>>
>>> Non-blocking filters are one example. If the data are not fully available, the filter releases the thread and waits for
>>> more data to come. Once the data are available, filter chain i resumed.
>>>
>>> But suspend is not the only extension. There may be other potential use cases, which we may not see yet. We are only
>>> starting with filters right now.
>>
>> It's a good idea to think about the future extensions and get prepared for then as much as possible early, but IMHO this
>> does not necessarily have to 'spill' into the interfaces, return types that filter developers will have to deal with
>> during their regular filter development, as I said in the initial response to your proposal,
>>
>> FilterContext can serve as an extension base very well too
>>
>> may be it should have a method such as
>> FilterContext.getContext(T class) right now and be done with it
>>
>> ex,
>>
>> filterContext.get(ExecutionContext.class).suspend
>>
>> Will that work ?
>
> So far I did not consider mixing execution context with filters. But in any case, why would you want to use the above
> instead of injection (e.g. JSR330 @Inject Provider<ExecutionContext> ec)?
>
Sure, that is fine too, but either way, if we talking about suspended
invocations then I just do executionContext.suspend() and that will
return via some RuntimeException the control back to the runtime
Cheers, Sergey
> Marek
>
>> Sergey
>>
>>
>>>
>>> Marek
>>>
>>>>
>>>> Cheers, Sergey
>>>>
>>>>> Bill
>>>>>
>>>>
>>
>>