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-5656) ContentType is removed for InternalServerError and doesn't seem to be a way to set a charset
Date Thu, 27 Mar 2014 16:57:16 GMT

    [ https://issues.apache.org/jira/browse/CXF-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13949579#comment-13949579
] 

Sergey Beryozkin commented on CXF-5656:
---------------------------------------

The workaround: add an out CXF interceptor which will set Message.ENCODING on the out message.

> 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
>            Assignee: Sergey Beryozkin
>             Fix For: 3.0.0, 2.7.11
>
>
> 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)

Mime
View raw message