The fact that JAX-RS matching algorithm does not support backtracking is not a mistake but a conscious decision made by Paul and Marc (the original authors of JAX-RS 1.0).
The idea was to make the algorithm fast and simple: Once a specific path template is matched, it is matched and there is no way back. You should remember and understand this concept and design your resource classes and methods with this concept in mind.
There would always be corner cases, no matter what we would do. If you start checking for equality results of float computations with an integral constant, you're in for a nasty surprise. Similarly, if you design your JAX-RS resources with different path templates that match overlapping URI paths, strange things start happen.
Marek
> On 12. 10. 2015, at 13:48, Grzesiek <gregory.d3_at_gmail.com> wrote:
>
> @Markus and @Marek
>
>> as no spec must break backwards behaviour ever
>
> Sorry, I understand you but I cannot agree. We are just humans, and every human makes mistakes - also those who are involved in creating the specification.
>
> Even core JDK is not so strict in the backward compatibility as you guys, at Jersey. Do you remember this java 1.7 item Updated sort behavior for Arrays and Collections? It affected a such core functionality like behaviour of the "Collections.sort" method. And since the java 1.7 every program that relied on that broken behaviour stopped to work and was throwing an IllegalArgumentException.
>
> If the previous behavior is desired, you can use the new system property: "-Djava.util.Arrays.useLegacyMergeSort".
>
>
> Current unintuitive/ strange/ buggy (choose whatever you want) behaviour in Jersey should definitely be changed.
>
>
> Greg
>
>
> 2015-10-12 10:38 GMT+02:00 Markus Karg <karg_at_quipsy.de>:
>> Mátyás
>>
>>
>>
>> feel free to suggest this product-specific solution to the Jersey Team by opening a JIRA ticket containing your proposal: https://java.net/jira/browse/JERSEY
>>
>>
>>
>> My personal feeling is that it will get rejected unless you provide a complete patch, as it implies work for Oracle for a feature not needed by that company.
>>
>>
>>
>> -Markus (JAX-RS Expert Group)
>>
>>
>>
>>
>>
>> Von: Mátyás Bene [mailto:matyas.bene_at_youstice.com]
>> Gesendet: Montag, 12. Oktober 2015 08:59
>> An: Markus KARG; users_at_jersey.java.net
>>
>>
>> Betreff: [Jersey] Re: Discussion about re-opening a bug: JERSEY-2942
>>
>>
>> So how about an "experimental" switch, that would control the method selection.
>>
>> You stay compliant with the specs (regardless of wether it is indeed broken our not) and the users will get the expected and intuitive behavior.
>>
>>
>>
>> M.
>>
>> -------- Original message --------
>>
>> From: Markus KARG <markus_at_headcrashing.eu>
>>
>> Date: 10/10/2015 13:12 (GMT+01:00)
>>
>> To: users_at_jersey.java.net
>>
>> Subject: [Jersey] Re: Discussion about re-opening a bug: JERSEY-2942
>>
>>
>>
>> What Marek wants to say is, despite how "strange" the behaviour is, as long as it is covered by the spec, we cannot change it, as no spec must break backwards behaviour ever.
>>
>>
>>
>> From: cowwoc [mailto:cowwoc_at_bbs.darktech.org]
>> Sent: Freitag, 9. Oktober 2015 23:18
>> To: users_at_jersey.java.net
>> Subject: [Jersey] Re: Discussion about re-opening a bug: JERSEY-2942
>>
>>
>>
>> Backwards compatibility is an admirable goal, but are you honestly saying that there are customers relying upon the current (seemingly broken) behavior, and they would be upset if it was changed?
>>
>> Gili
>>
>> On 2015-10-09 2:35 PM, Marek Potociar wrote:
>>
>> Markus,
>>
>>
>>
>> This has been discussed before in EG quite extensively. I can already promise you a big push back. As you should be aware of, we will not be able to introduce changes into JAX-RS that would break backward compatibility of the specification!
>>
>>
>>
>> Marek Potociar, JAX-RS Specification Lead
>>
>>
>>
>> On 07 Oct 2015, at 08:30, Markus Karg <karg_at_quipsy.de> wrote:
>>
>>
>>
>> To stop further confusion, I will take this question with me in the JAX-RS Expert Group forum and discuss it with all vendors, and report the result here.
>>
>>
>>
>> -Markus Karg, JAX-RS Expert Group
>>
>>
>>
>>
>>
>>
>>
>> Von: cowwoc [mailto:cowwoc_at_bbs.darktech.org]
>> Gesendet: Dienstag, 6. Oktober 2015 19:55
>> An: users_at_jersey.java.net
>> Betreff: [Jersey] Re: Discussion about re-opening a bug: JERSEY-2942
>>
>>
>>
>> +1
>>
>> At first glance, this definitely sounds unintuitive.
>>
>> Gili
>>
>> On 2015-10-06 3:29 AM, Grzesiek wrote:
>>
>> Hi all,
>>
>> A couple of weeks ago I've created a bug ticket JERSEY-2942. Unfortunately this ticket has been closed quite fast with the status "Works as designed". But I believe this is a misunderstanding.
>>
>> In the issue's comments you can read a short discussion on this topic.
>>
>>
>>
>> Generally, IMO current Jersey behavior is quite ridiculous, because when having exactly matching method to serve a GET /api/users/1request - Jersey chooses method annotated with @DELETE. No other JAX-RS implementations that I'm aware of (Apache CXF and RESTeasy) behaves this way.
>>
>>
>>
>>
>>
>> But I know I could be wrong here. What do you think?
>>
>> Any insights are appreciated.
>>
>>
>>
>> Regards
>>
>> Greg
>>
>