On Nov 18, 2008, at 1:52 PM, António Mota wrote:
> 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.
Still confused. Why do you want to do that? what is the higher level
goal? Are you writing your own support for dispatching HTTP requests
to resource classes? if do you are doing a lot of work that Jersey
already does for you.
Paul.