Hey Ron,
text/plain is more convenient for developers. Now WildFly reports and error and GF gives back something reasonable.
I would challenge that — but I have no idea how hard it is,
cheers,
adam
> On 01.03.2016, at 01:22, Ron Sigal <rsigal_at_redhat.com> wrote:
>
> Hey Adam,
>
> I wonder how the other implementations passed the TCK, given that "application/octet-stream" is supposed to be the default media type.
>
> In your opinion, then, is it worth challenging the four failing TCK tests?
>
> Thanks,
> Ron
>
>> Hi Ron,
>>
>> I noticed that, GlassFish and WLS were more lenient - they always returned the string representation of the resource, whereby WildFly reported an error.
>>
>> I’m for text/plain as default — it is more usable for developers,
>>
>> cheers,
>>
>> adam
>>
>> On 19.02.2016, at 19:21, Ron Sigal<rsigal_at_redhat.com> wrote:
>>
>> Hey everyone,
>>
>> Here at Red Hat we've been discussing a change in behavior from Resteasy 2 (JAX-RS 1.1) to Resteasy 3 (JAX-RS 2.0) related to the algorithm in Section 3.8 of the spec. In particular, there has been a change with respect to the use of MessageBodyWriters to determine the response media type in the absence of an Accept request header and the absence of relevant @Produces annotations, and it concerns our MessageBodyWriter defined
>>
>>> @Produces("text/plain")
>>> public class DefaultTextPlain implements MessageBodyReader, MessageBodyWriter
>>> {
>>>
>>> public boolean isWriteable(Class type, Type genericType, Annotation[] annotations, MediaType mediaType)
>>> {
>>> // StringTextStar should pick up strings
>>> return !String.class.equals(type) && !type.isArray();
>>> } ...
>> In Resteasy 2, the @Produces("text/plain") annotation on DefaultTextPlain is used to supply a media type in the absence any other determining information, so "text/plain" is, in effect, the default media type. In Resteasy 3, code has been added so that DefaultTextPlain is ignored, so that "application/octet-stream" is the default media type. Both generations of Resteasy pass their respective TCKs, but there is concern that the change in behavior will be a problem for users who upgrade from Resteasy 2 to Resteasy 3.
>>
>> Three points:
>>
>> 1. If we restore the earlier behavior, four TCK tests are broken:
>>
>>> * com/sun/ts/tests/jaxrs/spec/provider/writer/JAXRSClient.java#responseSubClassTest_from_standalone
>>> The test expects the media type to default to application/octet-stream and for a MessageBodyWriter specific to the test to get used, but DefaultTextPlain supplies a media type of text/plain, which rules out the expected MessageBodyWriter
>>>
>>> * com/sun/ts/tests/jaxrs/spec/provider/writer/JAXRSClient.java#supportNoneTest_from_standalone
>>> The test expects the media type to default to application/octet-stream and for there to be no usable MessageBodyWriters, but DefaultTextPlain gets used.
>>>
>>> * com/sun/ts/tests/jaxrs/spec/resource/responsemediatype/JAXRSClient.java#noProducesResponseReturnTest_from_standalone
>>> With no @Produces on the resources and no Accept header, the test expects the response to have media type application/octet-stream but gets text/plain
>>>
>>> * com/sun/ts/tests/jaxrs/spec/resource/responsemediatype/JAXRSClient.java#noProducesTest_from_standalone:
>>> Just like previous test.
>> 2. I don't see anything in the spec that would prevent us from using DefaultTextWriter to supply media type "text/plain". In fact, I notice that Marek said, in response to another issue, "section 4.2.4 of the spec does not preclude you from shipping a String MBW that declares in @Produces “text/plain” as well as “*/*” " (https://java.net/projects/jax-rs-spec/lists/users/archive/2015-02/message/14).
>>
>> 3. On the other hand, the new behavior, in which "application/octet-stream" is the default media type, seems to be closer to the spirit of the spec.
>>
>> Any thoughts?
>>
>> Thanks,
>> Ron
workshops.adam-bien.com
effectivejavaee.com
blog.adam-bien.com
airhacks.news
Author of:
"Real World Java EE Night Hacks”,
"Real World Java EE Patterns— Rethinking Best Practices"