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

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

OK, for 4xx return code(just like in your testcase), CXF client side will throw 
HTTPException and not set return code. Anyway, IMO it's no harm to set 4xx 
return code as well. The fix is coming soon.

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)

Reply via email to