On 02/12/11 10:33, Marek Potociar wrote:
>
>
> On Thu 01 Dec 2011 11:33:53 PM CET, 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.
>>>
>>
>> What makes me concerned as well here is that your proposed extensibility model is based on breaking FilterContext
>> interface every time such a new extension comes up.
>> As I said, I doubt that someone will ever come up with some bright idea for filters to do except for what can do now,
>> block request or modify the request info and ok, may be even suspend it. May be I'm ignorant but I can't imagine what
>> else can be invented for *filters* to do. Hence this extensibility idea of keeping FilterContext impls effectively
>> read only and having filter devs returning an opaque NextAction thing seems unusual to me to say the least.
>> But I got sidetracked there,
>>
>> Imagine users who have written their applications against JAX-RS 2.0 are now deploying their wars with the code built
>> against JAX-RS 2.0 API into containers with JAX-RS 3.0 API (with FilterContext supporting a new fly():NextAction
>> extension method) and suddenly this war fails to deploy because the filter was developed against the older version of
>> FilterContext
>>
>> Am I missing something ?
>
> Seems to me you are missing that adding a method to an interface that
> only impl. providers extend does not break BW compatibility. And since
> the continuation is processed in the framework, all new continuations
> are naturally supported by the framework.
Sounds OK this bit, thanks.
Sergey
P.S Still hate NextAction thing :-)
>
> Marek
>
>>
>> Thanks, Sergey
>>
>>> Marek
>>>
>>>>
>>>> Cheers, Sergey
>>>>
>>>>> Bill
>>>>>
>>>>
>>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com