CXF
  1. CXF
  2. CXF-4248

DocLiteralInInterceptor throws NPE if oneWay operation sends non-empty response

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4.8, 2.5.4, 2.6.1
    • Component/s: None
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      Hi,

      Test case: Web service provides oneWay operation (SoapUI mock), but sends non-empty SOAP response back
      Expected: response will be ignored
      Actual: DocLiteralInInterceptor throws NPE
      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)

      Fix proposal: I have discovered (thanks Aki!) that there are some cases when oneWay response can be proceeded. Regarding Basic Profile 1.1:
      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.

      I would propose to process successful oneWay responses only in following cases:
      A) if RM is active (check RMMessageConstants.RM_PROPERTIES_OUTBOUND, RMMessageConstants.RM_PROPERTIES_INBOUND)
      B) if user activate it with org.apache.cxf.transport.processOneWayResponse property on client.

      In other case oneWay response will be ignored by client.

      Patch is attached.

      Regards,
      Andrei.

      1. OneWayResponseProcessing-fixed.patch
        10 kB
        Andrei Shakirin
      2. OneWayResponseProcessing.patch
        7 kB
        Andrei Shakirin
      3. HTTPConduit.patch
        11 kB
        Andrei Shakirin

        Activity

        Hide
        Daniel Kulp added a comment -

        Patch would create a split-package issue between cxf-api and cxf-rt-ws-rm which would be a really bad thing.

        My suggestion would be to add a single property (your PROCESS_ONEWAY_REPONSE) to Message.java and have the HTTPConduit look for that. That WS-RM interceptors should SET that property on the message or exchange as part of the work they do.

        Show
        Daniel Kulp added a comment - Patch would create a split-package issue between cxf-api and cxf-rt-ws-rm which would be a really bad thing. My suggestion would be to add a single property (your PROCESS_ONEWAY_REPONSE) to Message.java and have the HTTPConduit look for that. That WS-RM interceptors should SET that property on the message or exchange as part of the work they do.
        Hide
        Andrei Shakirin added a comment -

        Hi Dan,

        Agree, proposed way is more elegant, because RMMessageConstants is not really fit for API package.
        Improved patch is attached.

        Andrei.

        Show
        Andrei Shakirin added a comment - Hi Dan, Agree, proposed way is more elegant, because RMMessageConstants is not really fit for API package. Improved patch is attached. Andrei.
        Hide
        Akitoshi Yoshida added a comment -

        Andrei's second patch set applied.

        Show
        Akitoshi Yoshida added a comment - Andrei's second patch set applied.
        Hide
        Akitoshi Yoshida added a comment -

        I noticed that the constant is incorrectly spelled (REPONSE). (okay, it's a valid french word, but that doesn't fit to the other constants.)

        so i mark this constant as deprecated and add the correctly spelled one (RESPONSE).

        Show
        Akitoshi Yoshida added a comment - I noticed that the constant is incorrectly spelled (REPONSE). (okay, it's a valid french word, but that doesn't fit to the other constants.) so i mark this constant as deprecated and add the correctly spelled one (RESPONSE).

          People

          • Assignee:
            Akitoshi Yoshida
            Reporter:
            Andrei Shakirin
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development