On Oct 19, 2012, at 2:00 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
> On 10/19/2012 6:18 AM, 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...
>>
>
> I don't see the user ever using getProviderInstances(), getProviderClasses(), getFeatureInstances(), getFeatureClasses(), getEnabledFeatures(). Why would the user ever write defensive code to see if features were enabled or not? Instead the feature should set a property the user can check if it is absolutely needed. As it is, its very awkward to iterate through a set of collections to find this information.
>
> For these methods only: (getProviderInstances(), getProviderClasses(), getFeatureInstances(), getFeatureClasses()) I see them onlyused by the client container itself when it has to instantiate a client with another Configuration
>
> Client client = ClientFactory.newClient(configuration);
>
> For getEnabledFeatures() I really don't see any use for it (see above).
I agree that these methods are not needed on the Configration. Which is also why I stated in my previous reply to Sergey that I would be in favor of separating client.Configuration from Configurable.
Marek
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com