users@jax-rs-spec.java.net

[jax-rs-spec users] Re: Question about "Determining the MediaType of Responses"

From: Adam Bien <abien_at_adam-bien.com>
Date: Thu, 25 Feb 2016 14:49:23 +0100

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
>