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

From: Marek Potociar <>
Date: Fri, 19 Oct 2012 17:54:51 +0200

On Oct 19, 2012, at 12:59 PM, Sergey Beryozkin <> wrote:

> On 19/10/12 11:46, Sergey Beryozkin wrote:
>> On 19/10/12 11:18, Marek Potociar wrote:
>>> On Oct 17, 2012, at 6:52 PM, Sergey Beryozkin<>
>>> wrote:
>>>> On 17/10/12 14:44, Marek Potociar wrote:
>>>>> On Oct 16, 2012, at 2:11 PM, Sergey Beryozkin<>
>>>>> wrote:
>>>>>> 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
>>> So you assume your users that register a feature do not need to check
>>> if there is such feature already enabled or see if the proper
>>> (pre-requisite) providers and/or properties are in place? Weird...
>> Please don't get me started. This is incredibly complex, this
>> Configurable interface, all for the purpose of meeting some uber-complex
>> edge cases.
>> Weird what ?
>> Why would you want a user, when using DynamicFeature for the purpose of
>> applying filters/interceptors in a fined grained manner to individual
>> methods worry about what features are installed and what
>> providers/interceptors those features may consist from, before making a
>> decision to register or not - it is just silly - the runtime should take
>> care of it
> Well, what I was actually going before your email, what about grouping
> all the getters into Configurable.Status interface and having a single getter, Configurable.getStatus() ?
> May be a bad idea, but here it is anyway

Trying to simplify the configuration API is not a bad idea at all IMO. In fact, I would like to split the client-side Configuration from Configurable interface somehow and make sure the Configuration is specialized in registering providers and features and Configurable is a deploy/initialization-time contextual concept used only by the features.


> Cheers, Sergey
>> Sergey
>>> Marek