Hi Paul
Thanks for the reply, it's so early there for you :-)
Would it make sense to update the specification slightly and note that if the Response is returned and
its metadata contains a Content-Type media type then it has to be taken into consideration ?
> Hi Sergey,
>
> I think the issue here is that the media type set by the resource class is not an acceptable media type.
>
> If the Accept header was:
>
> Accept : application/bar, application/foo
>
> then the media type returned for the Content-Type header would be "application/foo" and that media type would be passed to the
> MessageBodyWriter.writeTo().
>
> I think the the case you present there are a number of choices:
>
> 1) Return an not acceptable response, plus see the thread titled
>
> "status 406 if return object not serializable for POST, PUT,
> DELETE"
That's probably the best option.
>
> 2) Ignore the client accept header.
>
> 3) It is an error.
>
>
> There is also another case:
>
> @ProduceMime({"application/bar", "application/foo"})
> void Response get() {
> return response.ok().
> type(""application/baz").entity(someEntity).build();
> }
>
> IMHO i think this should be an error because it contradicts the declaration in @ProduceMime.
What if the Accept header allows for "application/baz" and there's a provider supporting this type available ?
I agree, perhaps the simplest and the best option is to have an error reported immediately. But given that the ResponseBuilder
allows for a type be set and that PorduceMime may not be visible to the application code (inherited from interface for ex), then may
be some extra checks can be done in the outbound chain first befroe reporting an error ?
Cheers, Sergey
>
> Paul.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland