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