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. HTTPConduit.patch
        11 kB
        Andrei Shakirin
      2. OneWayResponseProcessing.patch
        7 kB
        Andrei Shakirin
      3. OneWayResponseProcessing-fixed.patch
        10 kB
        Andrei Shakirin

        Activity

        Andrei Shakirin created issue -
        Andrei Shakirin made changes -
        Field Original Value New Value
        Attachment HTTPConduit.patch [ 12523319 ]
        Andrei Shakirin made changes -
        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 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 oneWay response 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 consumer

        In other case oneWay response will be ignored by client.

        Patch is attached.

        Regards,
        Andrei.
        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 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 consumer

        In other case oneWay response will be ignored by client.

        Patch is attached.

        Regards,
        Andrei.
        Andrei Shakirin made changes -
        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 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 consumer

        In other case oneWay response will be ignored by client.

        Patch is attached.

        Regards,
        Andrei.
        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 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.
        Andrei Shakirin made changes -
        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 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.
        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.
        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.
        Andrei Shakirin made changes -
        Attachment OneWayResponseProcessing.patch [ 12525023 ]
        Andrei Shakirin made changes -
        Attachment OneWayResponseProcessing-fixed.patch [ 12525025 ]
        Akitoshi Yoshida made changes -
        Assignee Aki Yoshida [ ay ]
        Hide
        Akitoshi Yoshida added a comment -

        Andrei's second patch set applied.

        Show
        Akitoshi Yoshida added a comment - Andrei's second patch set applied.
        Akitoshi Yoshida made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.6.1 [ 12320746 ]
        Fix Version/s 2.5.4 [ 12320747 ]
        Fix Version/s 2.4.8 [ 12320748 ]
        Resolution Fixed [ 1 ]
        Daniel Kulp made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        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).
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        36d 35m 1 Akitoshi Yoshida 25/May/12 10:01
        Resolved Resolved Closed Closed
        11d 4h 29m 1 Daniel Kulp 05/Jun/12 14:31

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development