users@jersey.java.net

[Jersey] Re: Access to method in a filter

From: Michal Gajdos <michal.gajdos_at_oracle.com>
Date: Wed, 30 Apr 2014 17:02:47 +0200

You can turn off WADL generation via
ServerProperties.WADL_FEATURE_DISABLE ([1]) property.

[1]
https://jersey.java.net/apidocs/latest/jersey/org/glassfish/jersey/server/ServerProperties.html#WADL_FEATURE_DISABLE

Michal

On 30.04.2014, 16:54 , Robert DiFalco wrote:
> 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
> don't suppose that is a configurable feature is it? I don't really use
> WADL, I use Miredot for documentation.
>
>
> On Wed, Apr 30, 2014 at 2:13 AM, Michal Gajdos
> <michal.gajdos_at_oracle.com <mailto:michal.gajdos_at_oracle.com>> wrote:
>
> Not really. For most of the cases dynamic features are configured
> at deployment time. In some cases (subresource locators
> represented by returned class or programmatically created
> resource) they are configured during runtime (when processing a
> request) but the overhead of this is minimal.
>
> Michal
>
>
> On 30.04.2014, 00:45 , Robert DiFalco wrote:
>> Any draw backs to conditionally adding the filter in a
>> DynamicFeature?
>>
>>
>> On Tue, Apr 29, 2014 at 12:32 PM, Michal Gajdos
>> <michal.gajdos_at_oracle.com <mailto:michal.gajdos_at_oracle.com>> wrote:
>>
>> Hi Robert,
>>
>> there are 3 possible choices for you:
>>
>> 1) (JAX-RS) inject ResourceInfo ([1]) into your
>> (post-matching) request filter
>> 2) (Jersey specific) if you need more info cast UriInfo into
>> ExtendedUriInfo ([2]) and look for getMatchedResourceMethod()
>> ([3])
>> 3) (JAX-RS) bind the container request filter directly to a
>> resource method - it's opposite approach than yours,
>> described here [4]
>>
>> [1]
>> https://jersey.java.net/apidocs/latest/jersey/javax/ws/rs/container/ResourceInfo.html
>> [2]
>> https://jersey.java.net/apidocs/latest/jersey/org/glassfish/jersey/server/ExtendedUriInfo.html
>> [3]
>> https://jersey.java.net/apidocs/latest/jersey/org/glassfish/jersey/server/ExtendedUriInfo.html#getMatchedResourceMethod()
>> <https://jersey.java.net/apidocs/latest/jersey/org/glassfish/jersey/server/ExtendedUriInfo.html#getMatchedResourceMethod%28%29>
>> [4]
>> http://blog.dejavu.sk/2014/01/08/binding-jax-rs-providers-to-resource-methods/
>>
>> HTH,
>> Michal
>>
>>
>> On 29.04.2014, 20:51 , Robert DiFalco wrote:
>>
>> 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
>> API authentication.
>>
>> 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
>> be invoked.
>>
>> 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!
>>
>>
>>
>
>