Thanks Michal, that seems to work well. Wow, stepping through it with
a debugger I sure see a lot of WADL related stuff come through. I
WADL, I use Miredot for documentation.
Not really. For most of the cases dynamic features are configured
at deployment time. In some cases (subresource locators
request) but the overhead of this is minimal.
Post by Robert DiFalco
Any draw backs to conditionally adding the filter in a
On Tue, Apr 29, 2014 at 12:32 PM, Michal Gajdos
1) (JAX-RS) inject ResourceInfo () into your
(post-matching) request filter
2) (Jersey specific) if you need more info cast UriInfo into
ExtendedUriInfo () and look for getMatchedResourceMethod() ()
3) (JAX-RS) bind the container request filter directly to a
resource method - it's opposite approach than yours,
described here 
Is there a way to access the Resource method that will be
called in a ContainerRequestFilter? I have a scenario
where I want Basic Authentication on my REST API. This
was a very simple filter to write. However, there are
some methods that I want to be unauthenticated.
My naive approach was to create an annotation
@Unauthenticated that I could either put on a Resource at
the class or method level. Then in my filter I could see
if this annotation exists and if it does skip my Basic
Unfortunately, while I *can* figure out how to get the
resource object in the filter by calling
'requestCtx.getUriInfo().getMatchedResources()' I can
*NOT* figure out how to get the method that is going to
So I can check for annotations at the class level but I
cannot figure out how to check for them at the method
level. Any guidance would be greatly appreciated!