Hi Paul,
thanks for correcting me.
I have filed an issue
https://jersey.dev.java.net/issues/show_bug.cgi?id=148 as suggested.
Thanks,
Naresh
Paul Sandoz wrote:
> Hi Naresh,
>
> What you point out is correct, i think there still is a bug in the
> matching algorithm as the second path should be matched for the second
> URL for *sub resource methods* i.e. if the @Path are used on a class
> or for sub-resource locators then this would be the correct behavior,
> but if @Path is used with @GET then there is a bug.
>
> The problem is that 3.7.2 [1] 2.d is not correctly honored:
>
> Filter E by matching each member against U as follows:
>
> * Remove members that do not match U.
> * Remove members derived from Tmethod (those added in step
> 2(c)i) for which the final capturing group value is
> neither empty nor ‘/’.
>
> The behavior as specified in the above second bullet is not happening.
>
> The paths are converted to the following regexes (in matching order):
>
> @Path("{domain}/x_report") -> ([^
> /]+?)}/x_report(/.*)?
>
> @Path("{domain}/{report_type}/{id}.{format}") -> ([^ /]+?)/([^
> /]+?)/([^ /]+?).([^ /]+?)(/.*)?
>
> The URL http://localhost/context/domain/x_report/123456.txt matches
> the first one with the final capturing could being ""/123456.txt", but
> it is not being rejected.
>
> Could you log an issue?
>
> Thanks,
> Paul.
>
> [1]
> https://jsr311.dev.java.net/nonav/releases/1.0/spec/spec3.html#x3-360003.7.2
>
> On Nov 24, 2008, at 10:40 AM, Srinivas Naresh Bhimisetty wrote:
>
>> Hi Darrin,
>>
>> what you are seeing is the correct behavior.
>>
>> The spec says -
>> Sort E using the number of literal characters in each member as the
>> primary key (descending order), the number of
>> capturing groups as a secondary key (descending order) and the number
>> of capturing groups with non-default regular
>> expressions (i.e. not ‘([^ /]+?)’) as the tertiary key (descending
>> order).
>>
>> In your case, the "/domain/x_report/" matches the first path string,
>> because the literal characters take precedence over the capturing
>> groups while doing pattern matches.
>>
>> Hope this helps,
>> Naresh
>>
>>
>> Darrin Holst wrote:
>>> Hello All,
>>>
>>> I have 2 resources:
>>>
>>> @Path("{domain}/x_report")
>>>
>>> @Path("{domain}/{report_type}/{id}.{format}")
>>>
>>> The first resource will create the "x" report and save it to disk.
>>> The second resource just serves the file back so it is able to
>>> handle any report type.
>>>
>>> So given http://localhost/context/domain/x_report the first resource
>>> is called and the file is generated. Now I want to get the file at
>>> http://localhost/context/domain/x_report/123456.txt, but the problem
>>> is I'm getting a 404 when I try. I would expect it to be mapped to
>>> the second resource, but it never gets there. If I remove the first
>>> Path annotation temporarily then the second resource request works.
>>> I've found some threads explaining the match process with regards to
>>> the number of literal characters and number of parameters, but
>>> http://localhost/context/domain/x_report/123456.txt shouldn't match
>>> the first resource, right?
>>>
>>> I was able to hack around the problem by changing the first resource
>>> to @Path("{domain}/{x: x_report}") so now they both have no literal
>>> characters and the second takes precedence because it has more
>>> parameters.
>>>
>>> Should this work like I think it should or am I missing something?
>>>
>>> Thanks,
>>> Darrin
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> <mailto:users-unsubscribe_at_jersey.dev.java.net>
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>> <mailto:users-help_at_jersey.dev.java.net>
>>
>