[
https://issues.apache.org/jira/browse/CXF-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14212150#comment-14212150
]
Sergey Beryozkin commented on CXF-6101:
---------------------------------------
The automatic negotatiation happens when the resource method selection is done,
when Accept is matched against @Produces. When a custom Response is created in
the exception mapper, the runtime can not block error responses if their format
(example, Response.status(500).type("text/plain").entity("Server
error").build()) does not match what the client Accepts (application/json)
because the client expectations are against the OK responses, the client must
get the correct error status and the message no matter what. If the runtime did
try to auto-negotiate at this point then it would return a misleading status
hiding the original error.
The exception mapper can get HttpHeaders contxt injected and get the most
preferred Accept type and set a Response type accordingly.
In your case it is slightly different, you have no CT set, but the runtime does
not know what type the entity is of; arguably the runtime could've
auto-negotiated at this point - but the spec requires it to default to
application/octet-stream if no CT has been set at this point.
I'd like to encourage you to ask at JAX-RS users list for more clarifications.
To be honest I'm not quite happy with a default application/octet-stream
either, but auto-negotatiating in cases like yours can cause its own
ambiguities, example, a user would report just
Response.status(500).entity("Server error").build(); and the client would get
in your case "Content-Type: application/json" followed by "Server error" which
would obvioulsy confuse the client too when it will do
Response.readEntity(MyJsonBean.class).
Cheers, Sergey
> Accept Header not Respected with Response from Custom MessageReader
> -------------------------------------------------------------------
>
> Key: CXF-6101
> URL: https://issues.apache.org/jira/browse/CXF-6101
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.0.2
> Reporter: Joseph Athman
> Priority: Minor
>
> I have created a custom MessageBodyReader class which implements the readFrom
> method and attempts to deserialize a JSON message using a specialized
> deserializer. If this fails for some reason, I am throwing a
> WebApplicationException with a Response build like this:
> {{Response.status(HttpStatus.BAD_REQUEST_400).entity(myCustomResponseObject).build()}}
> On the incoming request there is an Accept header which is respected when
> processing proceeds normally, but this header is not respected if I throw an
> exception in the readFrom method (content type of the response is always
> "text/xml"). The problem seems to be in the {{JAXRSInInterceptor}} class
> which creates a default message which does not have the exchange set on it,
> so when the createMessage method is invoked it is unable to find the correct
> content type so it will always default to "text/xml". Contrast the way this
> method works with how the {{ServiceInvokerInterceptor}} class creates a new
> message, it sets the exchange on the new message first before creating it.
> I realize I could set an explicit media type when creating the response but
> this seems to defeat the purpose of server side content negotiation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
