Maybe it would be more concise to name it "getRuntimeFeatures" vs.
"getUserFeatures" if I understood correctly the separation?
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Mittwoch, 17. Oktober 2012 15:44
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] Re: Please review:
> Feature, Configurable API update proposal.
>
>
> On Oct 16, 2012, at 2:11 PM, Sergey Beryozkin <sberyozkin_at_talend.com>
> wrote:
>
> > Hi,
> > On 15/10/12 22:52, Marek Potociar wrote:
> >> Ping...
> >>
> >> Unless there are any objections, I'd like to promote the proposal to
> >> an official change and start implementing it.
> >>
> >> Thanks,
> >> Marek
> >>
> >> On Oct 11, 2012, at 10:54 PM, Marek Potociar
> >> <marek.potociar_at_oracle.com <mailto:marek.potociar_at_oracle.com>>
> wrote:
> >>
> >>> Hello Experts,
> >>>
> >>> I would like to propose a following update to the Configurable API:
> >>> http://java.net/projects/jax-rs-
> spec/sources/git/revision/87d7e1ee01
> >>> 724344dc99c78637071bf085b7a4ab
> >>>
> >>> (Note: while it's in the Git, it is a proposal, not a given thing.
> >>> Feel free to discuss or raise objections. If we have to, we'll
> >>> remove it. I just figured it is much simpler to do it this way even
> >>> though I'm aware that there have been some reservations to the
> >>> approach in the past.)
> >>>
> >>> To sum up, I have tried to clarify and expand the Feature and
> >>> Configuration API javadoc based on the feedback from our RI
> >>> implementation team members. The main issue I tried to address is
> >>> when and in what order should the features be configured by the
> runtime.
> >>> The original javadoc seemed to suggest that the features have to be
> >>> configured directly in the register method. The goal of the
> proposal
> >>> is to give implementations more freedom in postponing the feature
> >>> configuration processing to any later more convenient time. This is
> >>> especially important when configuring client-side components.
> >>>
> >>> With that, I am also proposing a slight change in the Configurable
> API:
> >>>
> >>> - Renaming getFeatures() to getEnabledFeatures() method in order to
> >>> better indicate the actual data provided by the getter.
> >>> Additionally, I'm proposing to relax the requirements on when the
> >>> data provided by the method should become available (during feature
> >>> processing) and complete (after all features are processed).
> >>>
> >>> - Adding new getFeatureClasses() and getFeatureInstances() methods.
> >>> These methods seemed to be missing in terms of users not being able
> >>> to query the API which features have already been registered. Also,
> >>> it seems to me that it makes a lot of sense to keep the methods
> >>> separated from the similar existing provider-specific methods due
> to
> >>> the special role Features play in the configuration API.
> >>>
> >
> > 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).
>
> Marek
> >
> > Sergey
> >
> >>> Please review the proposal and let me know your feedback.
> >>>
> >>> Thanks,
> >>> Marek
> >>