Feature is a meta-provider. It has been designed as a way of grouping all providers and properties that are used in combination to provide some facility. It does not even make sense to "apply a feature" in any other context than to expand it into the actual set of providers and properties. The actual providers are those components that are really applied in the request processing context.
Btw. I have also replied to your comment on the issue:
http://java.net/jira/browse/JAX_RS_SPEC-293?focusedCommentId=349411&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_349411
In summary it is naive to think that what you're proposing would not have a negative impact on performance. As an implementor I know what I'm talking about. What you perhaps really want to propose is that there could be one or more constraint annotations that could be applied to providers so that runtime can do the request-specific conditional checks on behalf of those providers. E.g.
@ApplyIfPresent(HttpHeaders.CACHE_CONTROL)
public class CacheFilter implements ContainerResponseFilter { ... }
But that's a completely different story. The above is just a convenience feature and I'm not even sure if there's any code saved.
Marek
On Nov 2, 2012, at 7:55 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
> Yes this is correct, but see, the idea came up due to two aspects:
>
> (1) A feature might want to skip a filter by default, but only apply it if a
> given http header is set. Example: A "Microsoft Compatibility" feature might
> be installed with a JAX-RS application, and which applies a filter on all
> requests and an interceptor on all responses, if the request is sent from a
> Microsoft client (this is needed for WebDAV compatibility due to bugs in
> Microsoft's clients). Skipping filters completely (hence not invoking
> filter() at all) will not only improve workload due to the bypass
> processing, but also makes authoring the filter itself much simpler: The
> filter and interceptor does not need to check the headers anymore but can
> rely on the fact that it is only executed in case of a Microsoft request,
> must not set any custom properties to be passed to the interceptor, and the
> interceptor does not need to check custom properties to find out whether the
> request was sent by a Microsoft client. In the end, the feature is a lot
> simpler to code and to understand and the workload is improved.
>
> (2) Mapping features to http headers should be distinct from the actual
> action the feature implements, due to separation of concerns. Just as a
> JAX-RS resource implementation is separated from the method mapping in
> analogy. Possibly a resource shall only be invoked as reaction to particular
> headers, it would make sense to add an annotation to that resource method.
> The same annotation would be useable at features, too. So as long as it
> makes sense to separate concerns in resources, it makes sense to separated
> concerns in filters and interceptors, too.
>
> Regards
> Markus
>
>> -----Original Message-----
>> From: Bill Burke [mailto:bburke_at_redhat.com]
>> Sent: Freitag, 2. November 2012 18:14
>> To: jsr339-experts_at_jax-rs-spec.java.net
>> Subject: [jsr339-experts] Re: FW: Please discuss
>> http://java.net/jira/browse/JAX_RS_SPEC-293
>>
>> I don't think this is needed. You can just write a filter/itnerceptor
>> that checks to see if the header exists in the request or response and
>> bind these filters/interceptors globally.
>>
>> On 11/2/2012 12:56 PM, Markus KARG wrote:
>>> Experts,
>>>
>>> in a private discussion Jan and me thought it could be a good idea
>>> that DynamicFeature (as the word "dynamic" implies it) would include
>>> the possibility to bind filters to http headers, so I'd like to
>> invite
>>> you to discuss this proposal
>>> http://java.net/jira/browse/JAX_RS_SPEC-293 and to vote for it if you
>>> share our opinion. :-)
>>>
>>> Thanks
>>>
>>> Markus
>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>