[jax-rs-spec users] [jsr339-experts] Re: No way to disable a Feature

From: Sergey Beryozkin <>
Date: Tue, 13 Dec 2011 21:03:35 +0000

On 13/12/11 18:14, Bill Burke wrote:
> On 12/13/11 12:13 PM, Marek Potociar wrote:
>> On 12/13/2011 03:20 PM, Bill Burke wrote:
>>> On 12/13/11 6:11 AM, Marek Potociar wrote:
>>>> On 12/12/2011 03:48 PM, Bill Burke wrote:
>>>>> While the Feature interface has a onDisable() method, there's no
>>>>> way for the onDisable() method to be able to unregister
>>>>> providers. The Configuration.getProviderXXXX() methods return
>>>>> immutable sets.
>>>> Please clarify - are you suggesting to remove onDisable() and deffer
>>>> the disabling mechanism to the Feature
>>>> implementation or to add a common API for feature disabling?
>>> I'll clarify. The Configuration interface has no way to unregister a
>>> provider at the moment.
>> To follow up, my assumption was that while a provider can be
>> registered, disabling a feature does not mean the provider
>> is removed. I thought that it only means the feature will somehow set
>> a "disabled" property, that will be checked by the
>> provider whenever it is invoked. That's why I thought that adding more
>> mutability (to remove providers) is not
>> necessary. But if the above property-based solution for some reason is
>> not sufficient or practical, we can add a couple
>> of remove methods for providers.
> I'd really like disable to be removed altogether as I don't see it as
> very useful. Or at least see if users demand it and add it to JAXRS 2.1
> or something.
I reckon this usually depends on the request context and not managed in
such a coarse-grained manner as feature.disable, so I agree with Bill


> Also, if you insist on having disable, i would like a
> removeProvider/unregister method. Otherwise there's really no contract
> between Feature and the container on how to "disable" a filter/handler.
> Sure the Feature could set a boolean flag on the filter/handler, but the
> filter/handler will still be inserted into the call stack. I just don't
> htink this is nice or good practice.
> Bill

Sergey Beryozkin
Talend Community Coders