On 12/13/2011 10:03 PM, Sergey Beryozkin wrote:
> 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
See, this is the point of disable - to be able to temporarily disable a globally enabled feature for a particular URI
subtree or request. Once we add unregister/remove methods for providers, implementing onDisable in a feature will
suddenly become straightforward.
I lean towards this resolution path.
Marek
>
> Sergey
>
>> 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
>>
>
>