> > 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.
>
> What is the difference between a feature skipping a filter and a filter
> skipping itself? Answer: none. So, we don't need your proposal.
The difference is six steps to perform by the filter vendor, compared to one
step in the end. Please see my answer to Marek's post.
And yes, we do not *need* the proposal, but filter vendors will have an
easier life. In the end, it was simply a proposal for a new feature, not a
bug report about an essentially missing thing.
> > 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,
>
> You're talking about one line of code:
>
> class MSFilter extends ContainerRequestFilter {
>
> void filter(...) {
> if (ctx.getHeaderString("MS-HEADER") == null) return;
> }
> }
In reality it is much more code, please see my answer to Marek's post. It is
several things to check, not just one header-name, and it is a
response-interceptor which has to do that, which does not have access to the
request. So you spare many more things like custom properties etc.
> Plus, it will not improve workload because the container will have to
> dynamically create interceptor/filter chains *per-request*.
Please check the JIRA entry. I describes that there is no need for dynamic
chains as there can be a static skipping wrapper around that filter.
>
> > 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.
> >
>
> Point me to a real example on how this is simpler or more readable. In
> the end, this is not a performance improvement. IMO, it is not a
> readability improvement either.
Please check the answer I sent for Marek's post for this. It contains the
description of reality. In reality it reduces the feature's code by
approximately 10 to 20 lines of code and it adds no additional dynamic
workload as it uses a static skipping wrapper around the filter.
Regards
Markus