On 06/24/2011 04:42 PM, Bill Burke wrote:
>
>
> On 6/24/11 10:33 AM, Marek Potociar wrote:
> I wonder if the same functionality is not already covered by the current proposal, which gives a user the ability to
>>
>> - register filters and handlers for client, resource (link) and invocation
>> - inherit properties and features from the parent instance
>> - further customize the properties and features on each particular configurable instance (client, resource link and
>> invocation)
>> - access properties and features for each particular request/response (invocation) from within the filter/handler
>> implementation
>>
>
> 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.
>
IIUC, this is to solve grouping multiple filters into a single feature. For enabling/disabling you are using the
currently proposed String-based API.
I wonder why this needs to go in the spec. If necessary for the use case or its implementation, one can always create a
custom "feature" factory that would provide methods for properly configuring the feature on a configurable
(client/link/invocation) instance:
JBossJaxrsCache.configure(client);
or
JBossJaxrsCache.enable(client);
JBossJaxrsCache.disable(client);
...which does not expose any impl. details.
Marek