On 12/02/2011 12:35 PM, Sergey Beryozkin wrote:
> 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 :-)
I cannot stop wondering how a single interface can cause such strong feelings. :)
Marek
>
>>
>> Marek
>>
>>>
>>> Thanks, Sergey
>>>
>>>> Marek
>>>>
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>>> Bill
>>>>>>
>>>>>
>>>
>
>