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.
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
>>