[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Re: Re: Please review: Feature, Configurable API update proposal.

From: Santiago Pericas-Geertsen <>
Date: Mon, 22 Oct 2012 09:45:30 -0400

On Oct 22, 2012, at 5:09 AM, Marek Potociar wrote:

> Is feature enabled might make sense. Perhaps similarly, isProviderRegistered() might replace the getProviderClasses()/getProviderSingletons().
> Bill, Sergey, others, any comments?

 +1 on this suggestion to replace the getters.

-- Santiago

>> Maybe I still am missing some insight into this (while I AM a feature
>> provider, actually), but if there would ever be a need to find out whether a
>> particular feature is already installed, wouldn't it be the most intuitive
>> way to just ask "isFeatureEnabled(Feature)"? Or am I missing an essential
>> point with this simplification? I mean, is it of *any* use to know *why* or
>> by *whom* that feature was requested?
>>> -----Original Message-----
>>> From: Bill Burke []
>>> Sent: Freitag, 19. Oktober 2012 14:01
>>> To:
>>> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Re: Please
>>> review: Feature, Configurable API update proposal.
>>> On 10/19/2012 6:18 AM, Marek Potociar wrote:
>>>> On Oct 17, 2012, at 6:52 PM, Sergey Beryozkin <>
>>> wrote:
>>>>> On 17/10/12 14:44, Marek Potociar wrote:
>>>>>> On Oct 16, 2012, at 2:11 PM, Sergey
>>> Beryozkin<> wrote:
>>>>>>> What is the difference between getEnabledFeatures and
>>> getFeatureInstances ?
>>>>>> Features returned by getEnabledFeatures() are those ones that have
>>> been already enabled by runtime (i.e. the providers and properties
>>> registered by the feature are already part of the configuration).
>>>>>> OTOH getFeatureClasses() and getFeatureInstances() methods are just
>>> a list of all the features that have been registered (by the user) in
>>> the configuration. Please, check also the javadoc of the methods.
>>>>>>> Does getFeatureInstances include the instances instantiated from
>>> classes referred to from getFeatureClasses ?
>>>>>> No, it's just a list of all the features instances that were
>>> registered by the user (either using Configuration.register(Object,
>>> ...) on the client side or instances returned from
>>> Application.getSingletons() on the server side).
>>>>> Thanks... I'm a bit tired right now and thus feeling very slow :-),
>>> it took me a number of minutes to grasp the answer - hope Bill will do
>>> it for 5 secs :-). So far I'm just thinking that that Configurable
>>> implementation I prototyped for supporting DynamicFeature in CXF will
>>> have few extra empty methods added to it - which is where my concern
>>> is...
>>>>> Cheers, Sergey
>>>> So you assume your users that register a feature do not need to check
>>> if there is such feature already enabled or see if the proper (pre-
>>> requisite) providers and/or properties are in place? Weird...
>>> I don't see the user ever using getProviderInstances(),
>>> getProviderClasses(), getFeatureInstances(), getFeatureClasses(),
>>> getEnabledFeatures(). Why would the user ever write defensive code to
>>> see if features were enabled or not? Instead the feature should set a
>>> property the user can check if it is absolutely needed. As it is, its
>>> very awkward to iterate through a set of collections to find this
>>> information.
>>> For these methods only: (getProviderInstances(), getProviderClasses(),
>>> getFeatureInstances(), getFeatureClasses()) I see them onlyused by the
>>> client container itself when it has to instantiate a client with
>>> another Configuration
>>> Client client = ClientFactory.newClient(configuration);
>>> For getEnabledFeatures() I really don't see any use for it (see above).
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat