The DynamicFeature class in JAX-RS (2.0) allows you to register providers
- Dynamically i.e. without any pre-defined binding strategy (e.g. annotations)
- Based on criteria i.e. to help decide which provider to bind to which JAX-RS resource(s)
The JAX-RS implementation detects and executes the DynamicFeature implementations at deployment time
Here is an example where we instruct the JAX-RS run time to dynamically bind the AuthenticationFilter (a JAX-RS post construct filter) to be applied when a PUT is invoked on UserResource (which is a JAX-RS resource class)
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @Provider | |
| public class DynamicFilter implements DynamicFeature { | |
| @Override | |
| public void configure(ResourceInfo resInfo, FeatureContext ctx) { | |
| if (UserResource.class.equals(resInfo.getResourceClass()) && | |
| resInfo.getResourceMethod().getName().contains("PUT")) { | |
| ctx.register(AuthenticationFilter.class); | |
| } | |
| } | |
| } |
Criteria based
Criteria is provided by ResourceInfo and it’s based on 2 attributes
- the resource class, and
- the resource method
Dynamic
The dynamic registration is achieved using FeatureContext whose register method can be used to bind the provider
Note
@Providerusage is needed for automatic discovery by the JAX-RS run time- Applicable for – filters, interceptors and any
Feature - In case of filters, the following applicability criteria apply
- Post matching (
@PreMatchingfilters excluded) - Server side filters i.e.
ClientRequestFilterandClientResponseFiltercannot be registered using this method
- Post matching (
- Once used, it overrides other bindings (static or using
@NameBinding)
Head in the clouds 