[jax-rs-spec users] [jsr339-experts] Re: Re: Re: FilterAction and FilterContext

From: Sergey Beryozkin <>
Date: Thu, 1 Dec 2011 22:33:53 +0000

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 ?

Thanks, Sergey

> Marek
>> Cheers, Sergey
>>> Bill