[ https://issues.apache.org/jira/browse/CXF-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14209048#comment-14209048 ]
Joseph Athman commented on CXF-6101: ------------------------------------ This seems like a bug to me, but if this is not a bug I'd like to understand better what I'm doing wrong. > 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)