Well, it's not a huge issue but I still seem to get all the WADL package
classes and methods being processed/registered. Pretty much every wadl
package class/method gets passed into my DynamicFeature.
On Wed, Apr 30, 2014 at 8:02 AM, Michal Gajdos <michal.gajdos_at_oracle.com>wrote:
> 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>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
>> > 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()
>>> [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!
>>>>
>>>
>>>
>>
>>
>
>