Hi
Marek Potociar wrote:
> 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).
This fact should not be a concern for a user, the act of registering a
feature should result in all of the in/out filters/handlers constituting
this feature being registered under the hood. In other words,
registering a feature is a single step which is equivalent to multiple
steps for registering individual handlers.
>>
>> 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)
>>
IMHO, registering a feature with the client runtime should effectively
enable it and affect all the client instances. Alernatively, per-client
feature registration should be used...
>> 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.
I'd prefer per-client Feature registration or per-runtime (affecting all
the clients) one
thanks, Sergey
>
> Marek