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
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>