> 1. Remove isPartialResposne from HTTPConduit - this logic > isn't right as it depends on a certain HTTP response code. I > think the best way to test to see if we have a response > message is to just check and see if the contentType is null. > If it isn't, there is a message. If it is null, then there is > no message.
Well, null content-type or zero content-length, not sure which is most general and reliable indicator. Currently the logic is reponseCode == 202 && contentLenght != 0, so we could simplify this to contentLenght != 0, or check for null-ness of the content-type instead as you suggest. > 2. RM logic shouldn't need anything special now, just > recognition of a <SequenceAcknowledgement> in response to a > one way message. Remember the SequenceAcknowledgement could also be in a partial response to a twoway request (case B as described in an earlier mail on this thread). > 3. Remove isPartialResposne from ClientImpl. This call is > really superflous as we are going to return as soon as the > one way message is sent anyway - we aren't blocking for a > response since we check for isOneWay on line 160. We should > also change our logic so that we only look for response > objects if the call is one way. Are you assuming that partial responses are only sent for oneways? If that were the case, then the full/partial response recognition issue would indeed go away. But alas, case B requires that twoway requests may also attract partial responses. In this case, we would indeed be waiting for a full response in ClientImpl, so we need to be able to make the distinction between full and partial responses in ClientImpl, so I can't see how the ClientImpl.isPartialResponse() logic is superfluous. Recall the issue that got this whole discussion started ... distinguishing a partial and full response to a bare doc/lit *twoway* operation with void return type. The <SOAP:Body/> is empty in both responses, hence the need to distinguish in some other way. Cheers, Eoghan
