Is feature enabled might make sense. Perhaps similarly, isProviderRegistered() might replace the getProviderClasses()/getProviderSingletons().
Bill, Sergey, others, any comments?
Marek
On Oct 19, 2012, at 7:51 PM, Markus KARG <markus_at_headcrashing.eu> 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 [mailto:bburke_at_redhat.com]
>> Sent: Freitag, 19. Oktober 2012 14:01
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> 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 <sberyozkin_at_talend.com>
>> wrote:
>>>
>>>> On 17/10/12 14:44, Marek Potociar wrote:
>>>>>
>>>>> On Oct 16, 2012, at 2:11 PM, Sergey
>> Beryozkin<sberyozkin_at_talend.com> 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
>> http://bill.burkecentral.com
>