Sergey,
You should not tell your users that you are "somewhat" JAX-RS 2.0 compliant. From your reaction, you say that you do not do it, except for the earlier message on this forum. So I guess everything is ok, then.
If you want to be completely fair with your users, you should point out the areas where you know that you are not compliant with JAX-RS and make sure that users who attempt to use the non-compliant feature understand that their code will not be portable anymore. One such area is the matching algorithm when sub-resource method and sub-resource locator are bound to the same path template.
Marek
On 25 Mar 2014, at 18:03, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> Well, I've used a combination "early TCK compliance" in this very email, but I'm not seeing right now I've used 'TCK compliance' or 'JAXRS 2.0 compliance' in CXF forums. I'll take care of not using the 'compliance' word, hope it will keep things completely clean.
>
> Sergey
>
> On 25/03/14 16:39, Sergey Beryozkin wrote:
>> 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