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.
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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com