On 5/23/2013 11:00 AM, Marek Potociar wrote:
>
> On May 22, 2013, at 9:56 PM, Bill Burke <bburke_at_redhat.com> wrote:
>
>>
>> @Consumes("text/plain")
>> @POST
>> @Path("plain")
>> public void tckPOST();
>>
>> @Path("start")
>> @POST
>> public void start()
>>
>> @Path("start")
>> @POST
>> @Consumes("application/xml")
>> public void start(XML xml)
>>
>>
>> I have 2 different test cases whose solutions currently conflict.
>>
>>
>> Case #1:
>>
>> The TCK is posting a NULL entity with no Content-Type header to:
>>
>> POST /plain
>>
>> The TCK is expecting this to match tckPOST() even though two different sections of the spec conflict:
>>
>> - Section 4.2.1.1 Says that if the request does not contain a Content-Type, then application/octet-stream is used. This is for matching bodies though.
>
> Yes, I think that one should not apply to requests without a body.
>
>>
>> - The matching algorithm in Step 3(a) says:
>>
>> "The media type of the request entity body *(if any)* is supported by the input format"
>>
>> What does *if any* mean? The TCK seems to assume that if the Content-Type header is null, then the @Consumes annotation is ignored. Or am I supposed to look at the method to see if it is expecting a request body?
>
> I guess that's the correct interpretation. FWIW, the whole test is good in that it uncovers these hidden portability issues, but I would in this case even support removing the test as it is testing a completely artificial use case.
>
Only real way to test for a body is to either a) check the Content-Type
header is null or b) check the resource method to see if it expects a
body. So the 2 start() methods would be ambiguous so I'm free to match
them however I see fit. This is another user posted use case where they
want a no-param start() method to match if there is no content.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com