jax-ws
  1. jax-ws
  2. JAX_WS-1138

SOAPFaultException thrown by a SOAPHandler produces erroneous MTOM response

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.7, 2.2.8
    • Fix Version/s: None
    • Component/s: runtime
    • Labels:
      None

      Description

      I have a SOAPHandler that throws a SOAPFAULTException from the handleMessage() method like follows:

      String faultReason = "Something is missing.";
      QName faultCode = SOAPConstants.SOAP_SENDER_FAULT;
      fault = soapFactory.createFault(faultReason, faultCode);
      throw new SOAPFaultException(fault);
      

      When a client sends a multipart request that causes the mentioned SOAPFaultException, the jax-ws produces response like follows, that cannot be parsed by a .Net client:

      ---[HTTP response 500]---
      --null
      Content-Id: null
      Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
      Content-Transfer-Encoding: binary
      
      <?xml version='1.0' encoding='UTF-8'?>
      <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
        <S:Body>
          <S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope">
      	  <faultcode>ns4:Sender</faultcode>
      	  <faultstring>Something is missing.</faultstring>
      	</S:Fault>
        </S:Body>
      </S:Envelope>
      --null----------------------
      

      The .Net cleint cannot parse such response, probably due to "Content-Id: null" or "null" boundaries.
      The reponse was generated by version 2.2.7. Version 2.2.8 generates response like follows:

      ---[HTTP response 500]---
      ------=_Part_23_31110117.1387295878382
      Content-Id: <rootpart@soapui.org>
      Content-Type: application/xop+xml;charset=UTF-8;type="text/xml"
      Content-Transfer-Encoding: binary
      
      <?xml version='1.0' encoding='UTF-8'?>
      <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
        <S:Body>
          <S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope">
      	  <faultcode>ns4:Sender</faultcode>
      	  <faultstring>Something is missing.</faultstring>
      	</S:Fault>
        </S:Body>
      </S:Envelope>
      ------=_Part_23_31110117.1387295878382----------------------
      

      , where the "_Part_23_31110117.1387295878382" value was not generated by the jax-ws, but is taken from the request:

      ---[HTTP request]---
      accept-encoding: gzip,deflate
      connection: Keep-Alive
      content-length: 6566
      content-type: multipart/related; type="application/xop+xml"; start="<rootpart@soapui.org>"; start-info="text/xml"; boundary="----=_Part_23_31110117.1387295878382"
      host: localhost:8080
      mime-version: 1.0
      soapaction: ""
      user-agent: Apache-HttpClient/4.1.1 (java 1.5)
      
      ------=_Part_23_31110117.1387295878382
      Content-Type: application/xop+xml; charset=UTF-8; type="text/xml"
      Content-Transfer-Encoding: 8bit
      Content-ID: <rootpart@soapui.org>
      
      <soapenv:Envelope ...
      

      May the response reuse boundaries provided in the request? Should the boundaries values somehow relate to the Content-Id?

      Workaround throw a RuntimeException instead of SOAPFaultException, though in that case, you cannot control faultcode value: it will always be "Server"

      ---[HTTP response 500]---
      --uuid:2d993b2c-b70a-459c-984b-33758c3bfd31
      Content-Id: <rootpart*2d993b2c-b70a-459c-984b-33758c3bfd31@example.jaxws.sun.com>
      Content-Type: application/xop+xml;charset=UTF-8;type="text/xml"
      Content-Transfer-Encoding: binary
      
      <?xml version='1.0' encoding='UTF-8'?>
      <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
        <S:Body>
          <S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope">
            <faultcode>S:Server</faultcode>
      	  <faultstring>Something is missing.</faultstring>
      	</S:Fault>
        </S:Body>
      </S:Envelope>
      --uuid:2d993b2c-b70a-459c-984b-33758c3bfd31----------------------
      

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            vladkravchenko
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: