[
https://issues.apache.org/jira/browse/CXF-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-3916.
------------------------------
Resolution: Fixed
Fix Version/s: (was: 2.4.5)
(was: 2.5.1)
2.5.3
2.4.7
Added a testcase for this.
Basing on the presence or not of the callback is definitely not a correct fix
and the testcase I added actually proved it. A couple interceptors based
their actions on whether the message was a partial response or not and thus
things were not processed correctly. For example, in the testcase, the
response resulted in a ClassCastException as the WrapperClassInInterceptor does
not run if the response is a partial message so the contents List had the
wrapper object and not the expected integer. Also, with WS-RM, you can have
partial responses and such coming in whether or not you have a callback object.
I've updated the MAPAggregator to do some extra checks if the message is marked
a partial response to reset to a non-partial response if it feels it should be.
That fixes the test.
It would be great if you could try your cases with tonights snapshots (or build
your own snapshots).
> partial response problem with SOAP 1.1 use of WS-Addressing
> -----------------------------------------------------------
>
> Key: CXF-3916
> URL: https://issues.apache.org/jira/browse/CXF-3916
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 2.4.2
> Reporter: Jesse Pangburn
> Assignee: Daniel Kulp
> Priority: Minor
> Labels: client, dispatch, soap11, ws-addressing
> Fix For: 2.4.7, 2.5.3
>
>
> Description copied from email:
> I've read over this more and now see that the partial response stuff is
> definitely for asynchronous processing, so the check with the WS-Addressing
> relatesTo header makes sense. The problem (I think) appears in your checkin
> revision 705446 for ClientImpl.java in this section:
> {code}
> synchronized (message.getExchange()) {
> if (!isPartialResponse(message) && callback == null) {
> message.getExchange().put(FINISHED, Boolean.TRUE);
> message.getExchange().setInMessage(message);
> message.getExchange().notifyAll();
> }
> }
> {code}
> You added the "&& callback == null" test, but I think what is needed is "||
> callback == null". The idea here (again, as I'm reading it) is regarding
> these two cases:
> - it's an asynchronous response which is not a partial response
> - there is no callback, meaning it's a synchronous response
> In either of these cases you want to tell the exchange that it's finished and
> the message you just got is the inbound message. I think this worked for a
> long time without anyone running into this because in the synchronous case
> (callback == null), the only way you get a partialResponse==true is when
> WS-Addressing is engaged AND the server that you're connecting to doesn't
> return the optional (but almost always used) relatesTo header. Probably in
> the vast majority of cases either WS-Addressing isn't used or the relatesTo
> header is present in a response.
> If you agree, I can create a defect and describe this. Since the change is
> just && to ||, obviously it won't help to send you a patch file :-)
> Thanks,
> Jesse
> {code}
> -----Original Message-----
> From: Jesse Pangburn [mailto:jesse.pangb...@us.lawson.com]
> Sent: Wednesday, November 09, 2011 6:37 PM
> To: us...@cxf.apache.org
> Subject: partial response problem with SOAP 1.1 use of WS-Addressing and
> SOAPAction
> Hi,
> I invoked a SOAP 1.1 web service using CXF 2.4.2 DispatchImpl and that
> service immediately returned the following soap header:
> <soap:Header>
>
> <wsa:MessageID>uuid:A12B3727-0B3D-11E1-983D-DFB5348FF699</wsa:MessageID>
> <wsa:Action>response</wsa:Action>
> </soap:Header>
> My client hung for 60 seconds until a timeout was reached, at which point the
> response was available in the StaxSource. Tracing the problem into the code
> revealed that it was waiting because the message response it had received so
> far was deemed a "partial response" due to the following code which always is
> called when WS-Addressing is enabled in MAPCodec.java:
> private void markPartialResponse(SoapMessage message,
> AddressingProperties maps) {
> if (ContextUtils.isRequestor(message) && null != maps
> && (null == maps.getRelatesTo()
> || (null != maps.getRelatesTo()
> &&
> Names.WSA_UNSPECIFIED_RELATIONSHIP.equals(maps.getRelatesTo().getValue())))) {
> message.put(Message.PARTIAL_RESPONSE_MESSAGE, Boolean.TRUE);
> }
> }
> The problem, I think, is this condition "null == maps.getRelatesTo()". This
> essentially means that a WS-Addressing RelatesTo header is required to
> indicate that a message response is complete- even on a synchronous
> request/response. I think the source of this problem is that the original
> WS-Addressing submission to W3C said that "This element MUST be present if
> the message is a reply" in the description for the RelatesTo header (see
> http://www.w3.org/Submission/ws-addressing/#_Toc77464323). This language was
> struck from the final WS-Addressing 1.0 (see
> http://www.w3.org/TR/ws-addr-core/#msgaddrpropsinfoset) and means that
> RelatesTo is not required.
> While I think it was sloppy on the part of the service writer to not include
> the RelatesTo header, it is OPTIONAL according to the spec. So, especially
> in the case of a synchronous request, I think this code is incorrect. A CXF
> Dispatch client should not hang until timeout is reached because an optional
> header is not included in the response.
> Unfortunately, I'm not really sure what the correct solution is here since I
> don't understand the case for ever having a partial response message in a
> synchronous request/response. Should later code note that the
> request/response is synchronous and ignore this partial response flag? I
> assume the intention of this code is for asynchronous request/response so
> that the immediate response on the request's socket connection is not treated
> as the asynchronous response message.
> Any clues?
> Thanks,
> Jesse
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
