On Oct 19, 2012, at 12:59 PM, Sergey Beryozkin <sberyozkin_at_talend.com> 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<sberyozkin_at_talend.com>
>>> wrote:
>>>
>>>> On 17/10/12 14:44, Marek Potociar wrote:
>>>>>
>>>>> On Oct 16, 2012, at 2:11 PM, Sergey Beryozkin<sberyozkin_at_talend.com>
>>>>> 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.
Marek
>
> Cheers, Sergey
>
>>
>> Sergey
>>
>>> Marek
>>
>