[
https://issues.apache.org/jira/browse/CXF-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949391#comment-13949391
]
Andy Kane commented on CXF-5656:
--------------------------------
Yes, this is only for Responses returning status codes 500.
We trap for service exceptions using a class which extends ExceptionMapper
which receives the exception and returns a javax.ws.rs.core.Response object and
setting the status method to Response.Status.INTERNAL_SERVER_ERROR and the
message from the exception.
We then set the ContentType using a class which extends MessageBodyWriter with
charset=utf-8. I have tried all the status codes and only HTTP_INTERNAL_ERROR
(500) has the ContentType header replaced and re-added without the
Charset=utf-8.
Looking at the code source code for CXF, the AbstractHTTPDestination class only
removes the ContentType if the status is code is HTTP_INTERNAL_ERROR (500) .
Thanks Andy
> ContentType is removed for InternalServerError and doesn't seem to be a way
> to set a charset
> --------------------------------------------------------------------------------------------
>
> Key: CXF-5656
> URL: https://issues.apache.org/jira/browse/CXF-5656
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 2.7.7, 2.7.10
> Reporter: Andy Kane
>
> We have a Rest service that uses JAX-RS and CXF. When we used CXF 2.3.3, if
> there was a problem with the request and a non 200 status code was returned,
> the browser would display the message from the response with any encoded non
> ASCII characters as the ContentType returned application/json;charset=utf-8.
> After upgrading to 2.7.7, we noticed that non ASCII characters where not
> being encoded for Status 500 - Internal Server Error. This doesn't happen
> for any other status codes and we noticed that charset=utf-8 was being
> stripped from the ContentType. After looking through the CXF code, I noticed
> that the AbstractHTTPDestination class was removing the ContentType (line
> 553). The ContentType was then re-added in getContentTypeFromMessage method
> in the headers object without the Charset. Looking at this method, I noticed
> that the encoding was taken from Message.ENCODING and in our case this was
> null.
> There doesn't seem to be a way of setting
> org.apache.cxf.message.Message.ENCODING from either the ExceptionMapper or
> ExceptionMapper. I have also set the encoding type in the Response object in
> ExceptionMapper, but this doesn't seem to make much difference either.
> Removing the ContentType seems like a bug, as if the ContentType has been
> previously set and then this should be preserved. Is there a work around for
> this problem in the mean time.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
