Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Fri, 14 Nov 2014 11:41:35 +0000 (UTC)
From: "Sergey Beryozkin (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12754940.1415841598000.499433.1415965295900@Atlassian.JIRA>
In-Reply-To: <JIRA.12754940.1415841598000@Atlassian.JIRA>
References: <JIRA.12754940.1415841598000@Atlassian.JIRA>
 <JIRA.12754940.1415841598850@arcas>
Subject: [jira] [Resolved] (CXF-6101) Accept Header not Respected with
 Response from Custom MessageReader
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CXF-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sergey Beryozkin resolved CXF-6101.
-----------------------------------
       Resolution: Fixed
    Fix Version/s: 3.0.3
                   3.1.0
         Assignee: Sergey Beryozkin

may be I should've closed this issue as Invalid and opened another one related to defaulting to text/xml, but I'll close it as Fixed gievn that now application/octet-stream is set if no CT is available

thanks

> 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
>            Assignee: Sergey Beryozkin
>            Priority: Minor
>             Fix For: 3.1.0, 3.0.3
>
>
> 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)