On Jan 28, 2010, at 1:44 PM, Daniel Bimschas wrote:
> Yes, I was using jersey-core-1.0.2.jar :D
> That could explain it, thank you!
>
If you were using 1.0.2 then the issue i was referring to [1] was
already fixed in that release.
I verified modifying the helloworld sample [2] that the matching works
as expected with 1.1.5.
One explanation for the behavior is if you have configured URI content
negotiation for URI paths ending in the ".xml" prefix. If so Jersey
will remove if the ".xml" from the URI before it starts URI path
matching.
Paul.
[1]
https://jersey.dev.java.net/issues/show_bug.cgi?id=148
> cheers,
> Daniel
>
> Am 27.01.2010 um 18:49 schrieb Paul Sandoz:
>
>> What version of Jersey are you using?
>>
>> The @Path("abc/{var}.xml") should take precedence over @Path("abc/
>> {var}") because there are more literal characters in the former.
>>
>> There was a bug that was fixed in 1.0.2 that could result in such
>> behavior.
>>
>> Paul.
>>
>> On Jan 27, 2010, at 5:58 PM, Daniel Bimschas wrote:
>>
>>> I just tested further and I didn't write the @Produces tags to the
>>> methods below saying that getAbc() produces text/html and
>>> getAbcAsXML() produces application/xml.
>>>
>>> After trying the request with curl to be sure that no request
>>> headers ask for text/html I could find out that the CXF
>>> implementation delivers XML content, therefore doing the correct
>>> mapping.
>>>
>>> Watching debug output of CXF i saw that the browser produces the
>>> following request header:
>>>
>>> Accept=[text/html,application/xhtml+xml,application/xml;q=0.9,*/
>>> *;q=0.8]
>>>
>>> I don't know the specification for the interpretation of these
>>> headers but it seems Jersey and CXF do different here and one of
>>> the implementation favours the request headers more than the path
>>> mapping.
>>>
>>>
>>>
>>> Am 27.01.2010 um 17:39 schrieb Marc Hadley:
>>>
>>>> On Jan 27, 2010, at 10:59 AM, Daniel Bimschas wrote:
>>>>>
>>>>> I have a question regarding the correct mapping of URIs to JAX-
>>>>> RS methods. We have an implementation class that provides two
>>>>> methods as follows:
>>>>>
>>>>> @GET
>>>>> @Path("abc/{var}")
>>>>> public Response getAbc(@PathParam("var") var) { ... }
>>>>>
>>>>> @GET
>>>>> @Path("abc/{var}.xml")
>>>>> public Response getAbcAsXML(@PathParam("var") var) { ... }
>>>>>
>>>>> The JAX-RS specification says in 3.7.2 Request Matching under
>>>>> "3. Identify the method that will handle the request":
>>>>>
>>>>> "(c) The request is dispatched to the first Java method in the
>>>>> set5."
>>>>>
>>>>> While a set has no order this seems to be implementation
>>>>> dependent and/or "non-deterministic". Is this correct?
>>>>>
>>>>> As I suppose both methods are valid candidates for the set
>>>>> mentioned in the spec I wonder which method should be chosen.
>>>>> The problem (which is why I ask) is that Jersey choses
>>>>> getAbc(...) while the Apache CXF implementation choses
>>>>> getAbcAsXML(...) obviously interpreting the "something.xml" in
>>>>> the URI as the value for the path parameter. Is there a way to
>>>>> tell which behaviour is correct? Has one of the implementations
>>>>> a bug?
>>>>>
>>>> I would expect both implementations to use getAbcAsXML since step
>>>> 2.(h) only includes methods with the best matching URI template.
>>>> I think this may be a bug in Jersey.
>>>>
>>>> Marc.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>>
>>>
>>> ----------------------
>>> Daniel Bimschas
>>> Fleischhauer Strafle 45
>>> 23552 Lübeck
>>> daniel_at_bimschas.com
>>> ----------------------
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>>
>
> --
> M.Sc. Daniel Bimschas
> Institute of Telematics, University of Lübeck
> http://www.itm.uni-luebeck.de/users/bimschas
> Ratzeburger Allee 160, 23538 Lübeck, Germany
> Phone: +49 451 500 5389
>