[jira] [Commented] (CXF-8062) MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not 200

["Freeman Fang (JIRA)" <ji...@apache.org>]

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

Freeman Fang commented on CXF-8062:
-----------------------------------

Thanks [~tomasedata] for the reproducer, I will take a close look.

Freeman

> MessageContext.HTTP_RESPONSE_CODE cannot be obtained if response code is not 200
> --------------------------------------------------------------------------------
>
>                 Key: CXF-8062
>                 URL: https://issues.apache.org/jira/browse/CXF-8062
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 3.3.2
>            Reporter: Tomás García
>            Assignee: Freeman Fang
>            Priority: Major
>         Attachments: 200.png, 401.PNG, cxf_dependencies.PNG, cxfresponsecode.zip
>
>
> After a web service request, we do this:
> {code:java}
> responseCode = (Integer) ((BindingProvider) webServicePort).getResponseContext().get(MessageContext.HTTP_RESPONSE_CODE);
> {code}
> , to extract the Http response code, but we noticed that this only works in our case with 200 response codes from the server.
> From what I could gather, it seems that the response context is not populated in cases where a 200 is not given. Example:
> !401.PNG!
>  As you can see only two instances of SCOPES are in the response context. When we receive a 200 from the web service, the response context contains this:
>  !200.png! 
> , which although you can't see it in the screenshot, it contains the HTTP_RESPONSE_CODE value, which it's the only thing we need, because we need to do some additional steps depending on that response code afterwards.
> Right now, we're using a finicky way to obtain such http response code... the exception is a WebServiceException which contains a HTTPException which has the response code given by the server. We'd like to have a more reliable way since those exception signatures could just change over time if we update libraries / java versions we guess.
> Here's the CXF dependencies in our project:
>  !cxf_dependencies.PNG! 
> Let us know if you need to know about anything else. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)