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
http://bill.burkecentral.com