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