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

From: Marek Potociar <>
Date: Mon, 22 Oct 2012 11:09:51 +0200

Is feature enabled might make sense. Perhaps similarly, isProviderRegistered() might replace the getProviderClasses()/getProviderSingletons().

Bill, Sergey, others, any comments?

On Oct 19, 2012, at 7:51 PM, Markus KARG <> wrote:

> 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