I am developing a new application in JavaEE 7 using WildFly 8. I am using JAX-RS to provide a RESTful service interface for remote applications.
Something like an HttpHeaders
object can be injected in a resource method arguments using the @Context
annotation. Since the object is based on request parameters (of course, the HTTP headers), I came up with the idea of creating my own injectable User
object which is created based on the presence of a valid token in the request (something like an OAuth access token).
So, I want to achieve something like this:
@Path("/resources")
public class MyResource {
@Path("/{id}")
@GET
public Response getById(@Context User user, @PathParam("id") long id) {
...
}
}
Where User is an injectable object created based on request parameters, such as ones accessible through an HttpHeaders
object. Of course, the provider can also throw an exception and return an HTTP error response if the User object cannot be created for any reason.
Now, my questions are:
- Is this a good design? If not, what better options do I have?
- How can I achieve this? I do not care if my solution is not JAX-RS specific and uses WildFly/RestEasy-specific internals, but I definitely prefer a portable solution if there exists one.
Thanks
In my eyes this approach is valid as long as you don't try to build something like a session with this User Object.
As answered here you could use @Context and @Provider but that's not exactly what you want. Directly injecting a Class per
@Context
is possible with the Resteasy Dispatcher. But here you must register the Object which should be injected. I don't think that makes sense for request-scoped parameters. What you could do is inject a provider like this:Other ways to solve your problem:
I pushed examples to github.
While lefloh's answer is definitely correct I'd like to elaborate on his 2nd approach which I find most convenient.
You're to create Interceptor(Filter) which implements ContainerRequestFilter.
You'd need to register it either by autodiscovering set up in web.xml
or in your app boot
Since all the logic behind fetching the user is in the UserProvider you can for example use it like this