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

Xavier Coulon (JIRA) issues at jboss.org
Thu Mar 13 11:54:10 EDT 2014


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

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

    Description: 
(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.


  was:
(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) {
      ...
    }
}
{code}




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

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



More information about the jbosstools-issues mailing list