Hmm, I'm getting more doubts than before... Wich is a good thing cause
probably that means I wasn't understand enough of Jersey..
For now, let me just clarify this situation:
>>
>> But I don't understand exactly your explanation. What I'm doing
>> basically is looping to the abstractResource.getSubResourceMethods(),
>> get the UriPath of each and using a UriTemplate to match it, something
>> like
>>
>> for (AbstractSubResourceMethod subMethod :
>> abstractResource.getSubResourceMethods()) {
>> uriPath = subMethod.getUriPath().getValue();
>> uriTemplate = new UriTemplateRS(uriPath);
>> if (uriTemplate.matchExact(uri, map)) {
>> //do some more checks here
>> return subMethod;
>> }
>> }
>>
>
> Why are you doing that? is that for testing purposes?
>
> The order of the sub resource methods will not be returned in the matching
> order, it will be returned in declaration order (which is undefined in terms
> of Java reflection). The sorting according to paths happens else where, and
> needs to take both sub-resource locators and sub-resource methods into
> account.
That was the only way I found to match uri to paths. Actually, to do
that, I even extended a little the UriTemplate class. But I see that
if I can access all the paths in the spec order my problem will be
correctly solved. So where is that
>sorting according to paths happens else where, and
> needs to take both sub-resource locators and sub-resource methods into
> account. ?