Instead of changing the behaviour, a better solution might be to issue a
warning if the implementation finds a method which is effectively hidden by
some other method as the @GET method is hidden by @DELETE in this example.
Mark
On 12 October 2015 at 12: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
> <http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6804124>? 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 <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 <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.
>> <https://java.net/jira/browse/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/1*request -
>> Jersey chooses method annotated with *_at_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
>>
>>
>>
>>
>>
>>
>>
>
>