I've updated the top Apache CXF JAX-RS page as follows:
"CXF 3.0.0 completely implements JAX-RS 2.0 including new Client API and
has been fully tested against the first JAX-RS 2.0 TCK which became
available to Apache (jaxrstck-2.0_26-Feb-2013).
Note: CXF 3.0.0 can not claim at the moment the formal JAX-RS 2.0
compliance due to the fact that the final JAX-RS 2.0 TCK has not been
available to Apache"
Marek, hope it addresses your concerns. Please ping me privately or
publicly if you think more needs to be clarified. I think the above is
the honest and correct representation of the facts, and I'm personally
has never claimed that CXF 3.0.0 is "(fully) compliant" or that it has
passed JAX-RS 2.0 TCK - I'm always referring to the fact CXF passed the
very first TCK only.
And apologies if I lost it a bit
Sergey
On 25/03/14 16:13, Sergey Beryozkin wrote:
> 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