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/87d7e1ee01724344dc99c78637071bf085b7a4ab
>>
>> (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 ?
Sergey
>> Please review the proposal and let me know your feedback.
>>
>> Thanks,
>> Marek
>