[jira] [Commented] (CXF-3788) Allow CXF HTTP Client to handle HTTP 202 for twoway calls when the real response is sent back to the decoupled endpoint.

["Aki Yoshida (JIRA)" <ji...@apache.org>]

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

Aki Yoshida commented on CXF-3788:
----------------------------------

After running the entire systests, I found out that an additional check was required in HTTPConduit and ClientImpl before deciding to call callback.handleResponse() in HTTPConduit or return from ClientImpl without waiting.

More precisely, we need to avoid calling the handleResponse or quitting without waiting if a decoupled endpoint is supposed to be waiting for the real response. When callback.handleResponse is called, the callback's status is also set to done, although the real response is yet to arrive and the status should not be set done in that case. Similarly, when a request-response call is invoked with a decoupled endpoint, the ClientImpl gets 202 but it still needs to wait for the real response from the decoupled endpoint.

So, I needed to add this decoupled endpoint check in both places. Currently, the property name used is "org.apache.cxf.ws.addressing.MAPAggregator.decoupledDestination" and this name is defined as constant MAPAggregator.DECOUPLED_ENDPOINT in rt-ws-addr. 

Because of this, I am using this string value instead of this constant. But we should be defining a constant in Message. But I am not sure how and if we can replace this MAPAggregator's constant with this new constant. 


Our options are:
1. introduce a new constant in Message with another string and always set both properties at the same time
2. introduce a new constant in Message with the same string value and make MAPAggregator's constant simply refer to this new constant
3. introduce a new constant in Message with another string (one not containing "ws.addressing.MAPAggregator") and make MAPAggregator's constant simply refer to this new constant
4. replace the MAPAggregator's constant with the new constant of Message.
5. don't introduce a new constant in Message.

I think I prefer option 4 for 2.5.x and 3 for 2.4.x/2.3.x.

So, the problem itself has been resolved. But we will need to track this constant renaming/addition in another jira ticket.


> Allow CXF HTTP Client to handle HTTP 202 for twoway calls when the real response is sent back to the decoupled endpoint.
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CXF-3788
>                 URL: https://issues.apache.org/jira/browse/CXF-3788
>             Project: CXF
>          Issue Type: Bug
>          Components: Transports
>    Affects Versions: 2.3.6, 2.4.2
>            Reporter: Aki Yoshida
>            Assignee: Aki Yoshida
>             Fix For: 2.3.7, 2.4.3, 2.5
>
>
> CXF's HTTP Client can currently only handle HTTP 202 for oneway calls. This can lead to problems for twoway calls using a decouple endpoint when the server sends back the actual response to the decoupled endpoint and just an HTTP 202 response with no content to the HTTP response channel.
> This problem was not noticed until now in various CXF-to-CXF tests, as the CXF server returns an HTTP 200 with an empty SOAP envelope (not filled) to the HTTP response channel.
> But this behavior does not conform to the standard, it will be fixed with CXF-3768. CXF-366 and CXF-981 are also related to CXF-3768.
> This jira ticket is created so that this patch can be ported to the older releases. And this patch needs to precede the patch for CXF-3768.
>  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira