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

From: Bill Burke <>
Date: Tue, 16 Oct 2012 08:17:27 -0400

On 10/16/2012 8:11 AM, 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:
>>> (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 ?

BTW, why do we have these methods anyways? What is the purpose? Its
extra booking I'd just rather not do.

Bill Burke
JBoss, a division of Red Hat