[jax-rs-spec users] [jsr339-experts] Re: FW: Please discuss

From: Bill Burke <>
Date: Fri, 02 Nov 2012 18:22:40 -0400

On 11/2/2012 2:55 PM, Markus KARG 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.

What is the difference between a feature skipping a filter and a filter
skipping itself? Answer: none. So, we don't need your proposal.

> 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;

Plus, it will not improve workload because the container will have to
dynamically create interceptor/filter chains *per-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.

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.

Bill Burke
JBoss, a division of Red Hat