Provide support for server-side Filters and Interceptors

(See JAX-RS 2.0 spec., Chap.6)

Filters and Interceptors interfaces

As far as server-side JAX-RS is concerned, 4 types of interceptors should be support in the tooling:

public interface ContainerRequestFilter {
    void filter(ContainerRequestContext requestContext) throws IOException;
}
public interface ContainerResponseFilter {
    void filter(ContainerRequestContext requestContext,
        ContainerResponseContext responseContext) throws IOException;
}

public interface ReaderInterceptor {
    Object aroundReadFrom(ReaderInterceptorContext context)
throws java.io.IOException, javax.ws.rs.WebApplicationException;

public interface WriterInterceptor {
    void aroundWriteTo(WriterInterceptorContext context)
        throws java.io.IOException, javax.ws.rs.WebApplicationException;

User-defined Interceptors should implement one or more of those interfaces and should be annotated with @Provider to be automatically discovered. Without such annotation, they should be configured in the Application

Optionally, user-defined ContainerRequestFilter can also be annotated with @PreMatching to indicate that it should be executed upon receiving a client request but before a resource method is matched

Binding

Global binding is the default type of binding. A filter or interceptor that has no annotations is assumed to be bound globally, i.e. it applies to all the resource methods in an application. Like any other provider, a filter or interceptor can be registered manually (e.g., via Application or Configuration) or be discovered automatically. Note that for a filter or interceptor to be automatically discovered it MUST be annotated with @Provider.

A filter or interceptor can be associated with a resource class or method by declaring a new binding annota- tion à la CDI. These annotations are declared using the JAX-RS meta-annotation @NameBinding and are used to decorate both the filter (or interceptor) and the resource method or resource class.

For example:

@Provider
@Logged
class LoggingFilter implements ContainerRequestFilter,
                                  ContainerResponseFilter {
    ...
}

@Path("/")
public class MyResourceClass {

    @Logged
    @GET
    @Produces("text/plain")
    @Path("{name}")
    public String hello(@PathParam("name") String name) {
      ...
    }
}

@NameBinding
@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(value = RetentionPolicy.RUNTIME)
public @interface Logged { }

In this particular case, the binding annotation should be detected (same way as HTTP Methods) and the tooling should provide a way to navigate between the resource class or resource method and the associated/bound provider.

Binding annotations can also be applied to resource classes and Application subclasses. Binding annota- tions that decorate resource classes apply to all resource methods defined in them.

In that case,