On 12/01/2011 05:08 PM, Sergey Beryozkin wrote:
> 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
>
I'm afraid it is not designed to work that way at the moment namely because you can only resume with a response, which
makes sense in async resources, but would not be sufficient with filters, which need to resume with request most of the
time, but again, that does not make sense with resources... I may need to spend more time on it to see if what you
suggest would be viable.
That said, this topic in any case does not resolve my objections to your filter simplification proposal(s) (see my other
emails more on that).
Marek
> Cheers, Sergey
>
>> Marek
>>
>>> Sergey
>>>
>>>
>>>>
>>>> Marek
>>>>
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>>> Bill
>>>>>>
>>>>>
>>>
>>>
>