Hi,
Marek Potociar wrote:
> Hi Guilherme,
> please see also my other response to Bill.
>
> I am not a fan of String based programming either. However I don't want to end up with multiple ways for configuring
> filters/handlers in the API which would only complicate the filter/handler implementation. So just adding a new method
> for configuring stuff is not a good option.
>
> What I am thinking about instead is to consider filters/handlers as enabled whenever they appear in the invocation chain
> and provide a way for removing filters/handlers from the chain. We could then completely remove the string-based
> features. IOW, instead of:
>
> client.register(LoggingFilter.class);
> // ...send some logged requests
>
> client.disable(LoggingFilter.FEATURE);
> // ...send some requests quietly
>
> client.enable(LoggingFilter.FEATURE);
> // ...send some logged requests again
>
> ... one would do:
>
> client.register(LoggingFilter.class);
> // ...send some logged requests
>
> client.unregister(LoggingFilter.class);
> // ...send some requests quietly
>
> client.register(LoggingFilter.class);
> // ...send some logged requests again
>
>
> Would the above work better compared to string-based features? I understand that this is still not fully hiding the
> details of the filter - user needs to know whether to register a filter class or if it needs to be a singleton - but for
> a low-level API it is good enough for me.
Looks OK.
client.register(LoggingFilter.class);
registers and enables this filter and so should
client.register(LoggingFeature.class);
do IMHO
Sergey
>
> Marek
>
> On 06/25/2011 12:47 AM, Guilherme Silveira wrote:
>> I am a strong supporter of extracting an interface, even if a marker one. Using string properties leads us to String
>> oriented programming such as the enableFeature in the previous example.
>>
>> Compare string based programming:
>> Client.enableFeature(aString)
>>
>> Versus type based:
>> Client.enable(feature)
>>
>> I personally hate string based programming.
>>
>> Regards
>>
>> Guilherme Silveira
>>
>>> 2011. 6. 24. 오전 11:43에 "Bill Burke" <bburke_at_redhat.com <mailto:bburke_at_redhat.com>>님이 작성:
>>>
>>>
>>>
>>> On 6/24/11 10:33 AM, Marek Potociar wrote:
>>> I wonder if the same functionality is not already cove...
>>>
>>> Yes, a user could do all these things, but then the user would have to know the implementation detail of each feature.
>>> Some features may have more than one filter (i.e. caching).
>>>
>>> Think about if you were a caching provider for a JAX-RS client solution. In my proposal you would:
>>>
>>> 1. Write a Feature @Provider
>>>
>>> @Provider
>>> public class JBossJaxrsCache implements Feature {...}
>>>
>>> 2. Register the Feature with the JAX-RS Client runtime. (Features could also be registered automatically by the
>>> JAX-RS implementation by some scanning or other mechanism)
>>>
>>> 3. User creates Client and enables feature
>>>
>>> Client client = ...
>>> client.enableFeature("jboss.__caching");
>>>
>>> 4. The JBossJAXRSCache Feature is listening for "enableFeaature" events. It sees this event so it initializes a set
>>> of filters and registers them with the client.
>>>
>>> I'm just proposing a way to package up features.
>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>