> The assumption was that we need to be able to control the features up to the invocation level. Here's a potential use case:
>
> // All communication on this client is audited by default
> client.register(AuditingFilter.class);
>
> // adding a specific resource security filter for the link
> Link resource = client.link("http://some.resource/uri/").register(SomeResourceSecureHandler.class);
>
> This seems to be a common use case and we should support it.
So we have ClientConfiguration already letting users specify the
features - this is step 1. Creating a Client instance using a given
ClientConfiguration sets this Client with the list of those features and
thus presumably this Client will be 'affected' by those features.
SomeResourceSecureHandler.class above, has it been specified already in
ClientConfiguration or it's been specified in the above code only for
the 1st time ? If it's the former than that seems redundant, the latter
- looks ok
I'm trying get up to speed - apologies if I will ask questions which
have already been answered...
Cheers, Sergey
>
> Marek
>
> On 06/27/2011 02:00 PM, Sergey Beryozkin wrote:
>> I'd prefer per-client Feature registration or per-runtime (affecting all the clients) one