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