cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6101) Accept Header not Respected with Response from Custom MessageReader
Date Fri, 14 Nov 2014 11:29:34 GMT

    [ 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)

Mime
View raw message