On 02/12/11 12:25, Marek Potociar wrote:
>
>
> 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. :)
It is the opaqueness of it which kind of confuses me. I mean that is all
not a big deal after all, what to return or whether to return anything
at all, etc, it will work one way or another; guess it's a matter of
preferences, the generic chains I've had the experience recently all
return 'void' with the in-context offering the ways to affect the
processing which does not mean it's the only option of course, but hope
you see what I mean;
Sergey
>
> Marek
>
>>
>>>
>>> Marek
>>>
>>>>
>>>> Thanks, Sergey
>>>>
>>>>> Marek
>>>>>
>>>>>>
>>>>>> Cheers, Sergey
>>>>>>
>>>>>>> Bill
>>>>>>>
>>>>>>
>>>>
>>
>>