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
>> <mailto: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 <mailto: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 ticketJERSEY-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
>>
>