[jax-rs-spec users] [jsr339-experts] Re: Re: Re: Please review: Feature, Configurable API update proposal.

From: Marek Potociar <>
Date: Fri, 19 Oct 2012 12:14:42 +0200

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.


On Oct 17, 2012, at 6:08 PM, Markus KARG <> wrote:

> Maybe it would be more concise to name it "getRuntimeFeatures" vs.
> "getUserFeatures" if I understood correctly the separation?
>> -----Original Message-----
>> From: Marek Potociar []
>> Sent: Mittwoch, 17. Oktober 2012 15:44
>> To:
>> 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 <>
>> 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
>>>> < <>>
>> wrote:
>>>>> Hello Experts,
>>>>> I would like to propose a following update to the Configurable API:
>> 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