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