Hi Andrei, I may have to think it over but I think we should introduce a runtime property to ignore the response or to process it. The latter may lead to the rejection of the message depending on what is configured in the processing chain. The reason for using a property is that we cannot rely on the WS-RM artifacts only.
Basic-Profile 1.1 considered only simple oneway cases. In particular, there is no response and it must be ignored. This restricted behavior was changed in BP 1.2 to consider also the WS-RM and potentially other use cases that have this oneway with a non-empty response. ------ http://ws-i.org/profiles/basicprofile-1.2-2010-11-09.html#One-Way_Operations R2714 For one-way operations, an HTTP Response MESSAGE MAY contain an envelope. One-way operations typically do not produce SOAP responses. However, some INSTANCEs may choose to communicate infrastructure-related faults (e.g. MustUnderstand, VersionMismatch) in the HTTP Response message. In addition to this, the use of some protocol extensions (e.g. WS-ReliableMessaging) may create the possibility for non-empty responses to one-way messages. For these reasons the Basic Profile 1.1 requirement that the HTTP Response message not contain a SOAP envelope has been relaxed. ------- That means, we cannot just look for some WS-RM artifact and implicitly switch the behavior. Instead we should be using some property to switch the behavior explicitly. In that way, all uses cases can be supported. regards, aki 2012/4/13 Andrei Shakirin <[email protected]>: > Hi Aki, > > Use case was simple: I mock WS-Service using SoapUI and erroneously specified > non-empty response for oneWay method. > It caused NPE in DocLiteralInInterceptor: > > Caused by: java.lang.NullPointerException > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.shouldWrapParameters(DocLiteralInInterceptor.java:292) > at > org.apache.cxf.interceptor.DocLiteralInInterceptor.handleMessage(DocLiteralInInterceptor.java:103) > at > org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:263) > at org.apache.cxf.endpoint.ClientImpl.onMessage(ClientImpl.java:799) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponseInternal(HTTPConduit.java:1627) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleResponse(HTTPConduit.java:1494) > at > org.apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.java:1402) > at > org.apache.cxf.transport.AbstractConduit.close(AbstractConduit.java:56) > at > org.apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.java:649) > at > org.apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSende > rInterceptor.java:62) > > I am looking for the best way to fix it in CXF and would like firstly to > understand why responses for oneWay operations are processed at all. > > Question regarding acknowledgement messages in WS-RM: do such exchanges have > any marker to distinguish them from other cases (SOAP Headers, policies, etc)? > From my perspective the best solution will be just to reject interceptor > chain for non-empty oneWay responses for all cases except WS-RM, but WS-RM > must be somehow recognized. > > What do you think? > > Regards, > Andrei. > > > -----Original Message----- > From: Aki Yoshida [mailto:[email protected]] > Sent: 13 April 2012 10:04 > To: [email protected] > Subject: Re: oneWay: chunked partial response and two way decoupled use cases > > Hi Andrei, > This case (i.e., a oneway call needs to process a non empty http 200 > response) occurs in one specific configuration options in WS-RM. > > WS-RM supports several options for embedding (or exchanging) the > acknowledgement messages that are sent from the message receiver back to the > message sender. For oneway application services, you can configure these > acknowledgement messages to be either sent back directly in the http response > or sent back using a separate http request. In the former case, the response, > if it is there, needs to be processed as it may contain the SOAP message with > the WS-RM acknowledgement header. > > How does the NPE case you are analyzing look like? > > regards, aki > > 2012/4/12 Andrei Shakirin <[email protected]>: >> Hi, >> >> I am analysing NPE for case of non-empty oneWay operation response. >> >> Digging into HTTPConduit code I found two situations where non-empty oneWay >> response is interpreted as valid in- message and processed: >> >> 1. oneWay chunked partial response >> >> 2. twoWay decoupled partial response >> >> Criteria to process this responses even if exchange is onWay are: >> HttpHeaderHelper.TRANSFER_ENCODING = HttpHeaderHelper.CHUNKED or >> HttpHeaderHelper.CONNECTION = HttpHeaderHelper.CLOSE >> >> Just curious what is the real use case for client to process oneWay >> responses? Is it standard or CXF extensions? >> >> Regards, >> Andrei.
