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
>>>>
>
>