[jbosstools-issues] [JBoss JIRA] (JBIDE-16753) Provide support for server-side Filters and Interceptors

[Xavier Coulon (JIRA)]

     [ https://issues.jboss.org/browse/JBIDE-16753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Xavier Coulon updated JBIDE-16753:
----------------------------------

    Fix Version/s: 4.2.0.Beta1
                       (was: 4.2.0.Beta2)

    
> Provide support for server-side Filters and Interceptors
> --------------------------------------------------------
>
>                 Key: JBIDE-16753
>                 URL: https://issues.jboss.org/browse/JBIDE-16753
>             Project: Tools (JBoss Tools)
>          Issue Type: Sub-task
>          Components: webservices
>            Reporter: Xavier Coulon
>            Assignee: Xavier Coulon
>             Fix For: 4.2.0.Beta1
>
>
> (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:
> {code}
> 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;
> {code}
> 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*
> {quote}
> 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. 
> {quote}
> For example:
> {code}
> @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 { }
> {code}
> 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.
> {quote}
> 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.
> {quote}
> In that case, 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira