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.
Marek
>
> Thanks, Sergey
>
>> Marek
>>
>>>
>>> Cheers, Sergey
>>>
>>>> Bill
>>>>
>>>
>