cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glynn, Eoghan" <>
Subject RE: Identification of Partial Responses
Date Thu, 11 Jan 2007 17:19:56 GMT
> 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
> 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.


View raw message