Skip to main content
Last updated November 08, 2011 16:40, by spericas
Feedicon  
==Filters and Handlers Revisited ===Make Global Binding the Default Drop support for @GlobalBinding and make this binding the default for all filters and handler classes that are only annotated with @Provider. If a filter or handler is decorated with an annotation derived from @NameBinding, they are considered local not global. ===ResourceInfo Allow injection of a new class <tt>ResourceInfo</tt> that will provide resource class and method information. This information will be removed from <tt>FilterContext</tt> --thus, removing the <tt>BaseContext</tt> class. For example: <pre name="java"> @Provider public class LoggingFilter implements RequestFilter { public RequestFilter(@Context ResourceInfo ri) { ... } ... } </pre> Note that as explained in Section 9.1 of the spec, the instance injected must be capable of selecting the correct <tt>Resourceinfo</tt> during a request-response cycle. Injection of <tt>ResourceInfo</tt> is only supported as part of the server API. ===Pre-Match Filters A new interface is proposed to support the new <tt>PreMatch</tt> extension point. Filters defined for this extension point will be executed before resource matching and are, therefore, capable of altering the outcome of the JAX-RS matching algorithm (e.g., by updating the HTTP method in the request). This interface will use the same <tt>FilterContext</tt> as <tt>RequestFilter</tt> and <tt>ResponseFilter</tt>. <pre name="java"> @Provider public class HttpMethodOverrideFilter implements PreMatchRequestFilter { FilterAction preMatchFilter(FilterContext ctx) throws IOException { ... } } </pre> Restrictions: * Server API only * Pre-match filters are global in nature, any name binding derived annotations on the filter class are ignored * The DynamicBinding interface is also ignored * Only handlers that are bound globally will be executed whenever a pre-match filter reads or writes an entity (which should be rare) * During the pre-match phase, methods of an injected <tt>ResourceInfo</tt> will return null If a filter needs to be executed before and after resource matching, it can implement the corresponding interfaces. For example, a logging filter may be installed before and after matching: <pre name="java"> @Provider public class LoggingFilter implements RequestFilter, PreMatchRequestFilter { FilterAction preFilter(FilterContext ctx) throws IOException { logRequest(ctx.getRequest()); } FilterAction preMatchFilter(FilterContext ctx) throws IOException { logRequest(ctx.getRequest()); } } </pre> Just like other filters, pre-match filters must be sorted by binding priorities (<tt>@BindingPriority</tt>) --but there is no way to specify a binding priority that is different pre and post matching for those filters that are part of both chains. ===Single Class, Multiple Filters As seen in the last section, it is possible for a single class to implement multiple filters. Let's take a look at a few examples: <pre name="java"> @Provider @Logged public class LoggingFilter implements RequestFilter, PreMatchRequestFilter { ... } </pre> This filter uses name binding via <tt>@Logged</tt>. However, as stated above, this annotation will be ignore during the pre-match phase, so this filter will be part pre-match chain in all requests, as well as in the post-match chain for all resource methods decorated with <tt>@Logged</tt>. <pre name="java"> @Provider public class LoggingFilter implements RequestFilter, DynamicBinding, PreMatchRequestFilter { ... } </pre> In this example, the <tt>DynamicBinding</tt> interface only applies to <tt>RequestFilter</tt>, as stated above it is ignore in the pre-match phase. This filter will be part of the pre-match chain for all requests, as well as the post-match chain for all resource methods for which <tt>DynamicBinding.isBound()</tt> returns true at deploy time. For the sake of clarity, it should be recommended that classes implementing <tt>PreMatchRequestFilter</tt> do not implement any other interfaces. Also, it should be recommended to use pre-match filters only when the input to the matching algorithm needs to be modified. ===JAX-RS 2.0 Pipeline Putting it all together, the server-side pipeline (naturally, no support for pre-match binding on client side) would look like this: [[image: jaxrs_pipeline.png | 700px]]
 
 
Close
loading
Please Confirm
Close