[jax-rs-spec users] [jsr339-experts] Re: Re: JAX_RS_SPEC-21

From: Sergey Beryozkin <>
Date: Mon, 17 Sep 2012 17:40:32 +0100

On 17/09/12 17:30, Bill Burke wrote:
> Santiago. I thought you were spot on in the comments. Either the user
> can use explicit @OPTIONS resource methods and/or write a response
> filter. We just need to make sure response filters are run in error
> conditions.

That introduces a possible inconsistency between the default runtime
processing and the custom one - in the latter all depends on the user
doing that interceptor - which is problematic on its own: the runtime
knows better what HTTP methods are supported by a given handler as
opposed to the user code.


> On 9/17/2012 10:24 AM, Santiago Pericas-Geertsen wrote:
>> On Sep 17, 2012, at 9:22 AM, Sergey Beryozkin wrote:
>>> On 06/09/12 19:22, Santiago Pericas-Geertsen wrote:
>>>> Hello Experts,
>>>> If you have an opinion on the matter, please chime in on this
>>>> discussion:
>>>> <>
>>> I agree with the original idea, think that the runtime should be
>>> responsible for making sure Allow is always in the response to OPTIONS
>> The proposal in that issue was a bit more involved than that. But
>> let's assume we just do what you suggest. I.e., allow users to
>> implement @OPTIONS and then intercept the response to add Allow if not
>> there. I'm assuming we'd do that before running the response filter
>> chain.
>> Is this sufficient for all cases? Is this really more intuitive than
>> writing a filter that updates the default response?
>> -- Santiago