[jax-rs-spec users] Re: ContainerRequestFilter - acccess to method or annotations?

From: Marek Potociar <>
Date: Wed, 17 Oct 2012 17:47:36 +0200

On Oct 16, 2012, at 9:41 PM, Jan Kronquist <> wrote:

> Hi
> I'm trying ContainerRequestFilter and was wondering if there is any way to get the resource method or annotations of the resource method?
> Using the UriInfo I can access the resources, but not the method, ie
> requestContext.getUriInfo().getMatchedResources();
> In a ContainerResponseFilter I can access the annotations using: responseContext.getEntityAnnotations()
> Is there a reason why such a method is not available?

The reason why it's not part of the context is that some container request filters (pre-matching) are executed before the information is available. In any case, according to the spec, you should be able to inject ResourceInfo into your (post-matching) filters and get the information you're asking for. (Please read about the impl. status below)

> I would prefer to have access to all methods including subresource-methods.

Hmm... access to sub-resource methods is not possible at the moment. At the same time, I'm not convinced about the use case.

> Or should I use ResourceInfo? How should the injection work? Is there an implementation supporting this? (I have tested with jersey-2.0-m9)

Yes. Yes. No. :)

Unfortunately, thanks to your email I've just realized that ResourceInfo injection implementation in Jersey slipped through the cracks somehow. I've created a new Jira issue to track this one to make sure we'll deliver the support in 2.0-m10: (don't worry about the "Fix versions" field on the issue, it's just our way of tracking issues that need to be fixed as part of the current sprint, but we did not plan for them initially).

(Hint: as a temporary workaround, you may try to inject UriInfo in your filters and cast it to ResourceInfo in Jersey ;))

> However, ResourceInfo does not contain the subresource classes or methods?

No it does not. Filters are applied to a final resolved resource, not to sub resource locators. What is the use case you're looking at?


> /Jan