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