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

From: Sergey Beryozkin <>
Date: Tue, 16 Oct 2012 13:11:42 +0100

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:
>> (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 ?

Does getFeatureInstances include the instances instantiated from classes
referred to from getFeatureClasses ?


>> Please review the proposal and let me know your feedback.
>> Thanks,
>> Marek