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)?
Marek
> Sergey
>
>
>>
>> Marek
>>
>>>
>>> Cheers, Sergey
>>>
>>>> Bill
>>>>
>>>
>
>