Relax Marek. And don't bother using 'bold' style, I can read it without
it. I haven't talked about it here for you to educate me.
Go and get your layers check CXF archives or wiki, they won't find us
claiming the full compliance. And besides there was TCK available to
Apache, and I'm saying CXF passed that TCK except for the tests I tried
to challenge (pending Geronimo JIRA is there).
On 25/03/14 16:04, Marek Potociar wrote:
>
> On 18 Mar 2014, at 17:54, Sergey Beryozkin <sberyozkin_at_talend.com
> <mailto:sberyozkin_at_talend.com>> wrote:
>
>> Yes, Apache did not get the access to the latest one unfortunately,
>> only to the early one, where one of the tests has this issue as far as
>> I remember. So yeah, we have the early TCK compliance only - something
>> I'm honestly referring to :-).
>
> FYI, you *do not* have a compliance. There's nothing like early TCK
> compliance. You should not claim to be JAX-RS 2.0 compliant *in any way
> *unless you have passed the final JAX-RS 2.0 TCK.
>
> Marek
>
>>
>> By the way, recall that if you do something like
>> "@Path("subresource/sub/{id}")" then a subresource locator wins -
>> which is really not right, meaning that it wins in this case, but
>> loses in the other case...
>>
>> Cheers, Sergey
>>
>> On 18/03/14 16:47, Bill Burke wrote:
>>> I guess you haven't passed the TCK yet then. :)
>>>
>>> On 3/18/2014 12:45 PM, Sergey Beryozkin wrote:
>>>> The fact a sub-resource is discarded per the spec in this case is indeed
>>>> a major spec issue, can really affect the spec quality as seen by the
>>>> users. FYI, I did not bother updating CXF to get subresources ignored in
>>>> the case like the one below...
>>>>
>>>> Thanks, Sergey
>>>>
>>>>
>>>> On 18/03/14 16:38, Bill Burke wrote:
>>>>> Yet another user complaining about the JAX-RS matching algorithm...
>>>>>
>>>>> Enjoy! More to follow :)
>>>>>
>>>>>
>>>>> -------- Original Message --------
>>>>> Subject: [Resteasy-developers] Upgrading from 2.3.3 to 3.0.6
>>>>> Date: Tue, 18 Mar 2014 11:34:30 -0400
>>>>> From: XXXXXX
>>>>> To: resteasy-developers_at_lists.sourceforge.net
>>>>> <mailto:resteasy-developers_at_lists.sourceforge.net>
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> We're attempting to move from 2.3.3 (final) to 3.0.6 (final) and
>>>>> experiencing a few issues. One is an apparent change to the matching
>>>>> algorithm - for example, we have...
>>>>>
>>>>> @Path("path")
>>>>> public interface Resource
>>>>> {
>>>>> @Path("subresource/{id}")
>>>>> SubResource get(@PathParam("id") String id);
>>>>>
>>>>> @PUT
>>>>> @Path("subresource/{id}")
>>>>> String open(@PathParam("id") String id);
>>>>> }
>>>>>
>>>>> public interface SubResource
>>>>> {
>>>>> @DELETE
>>>>> String close();
>>>>> }
>>>>>
>>>>> Previously that would work fine. Now we get an exception / 405 code
>>>>> because it finds the PUT (only/instead). If I comment out the PUT,
>>>>> then
>>>>> the DELETE gets called fine. What is the best way to address this?
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com