If you think your names are more explanatory, then I think I still
misunderstood their particular uses.
> -----Original Message-----
> From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
> Sent: Freitag, 19. Oktober 2012 12:15
> 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.
>
> FWIW, personally, I don't find those names more explanatory. But if
> more people find the names better, I don't feel strongly about it.
>
> Marek
>
> On Oct 17, 2012, at 6:08 PM, Markus KARG <markus_at_headcrashing.eu>
> wrote:
>
> > 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
> >>>>
> >
> >