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 <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 ?
>
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
http://bill.burkecentral.com