On 17/10/12 14:44, Marek Potociar wrote:
>
> 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).
>
Thanks... I'm a bit tired right now and thus feeling very slow :-), it
took me a number of minutes to grasp the answer - hope Bill will do it
for 5 secs :-). So far I'm just thinking that that Configurable
implementation I prototyped for supporting DynamicFeature in CXF will
have few extra empty methods added to it - which is where my concern is...
Cheers, Sergey
> Marek
>>
>> Sergey
>>
>>>> Please review the proposal and let me know your feedback.
>>>>
>>>> Thanks,
>>>> Marek
>>>
>