Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-502

Soap envelope rpc-encoded namespace issue

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.6
    • Fix Version/s: 1.5.7
    • Component/s: Core, XML
    • Labels:
      None

      Description

      I have an rpc-encoded soap envelope containing the declarations of soapenv (xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/") and xsi (xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance") namespaces.
      The first element of the soap body references soapenv in one of his attributes (soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"). Some xml elements in the soap body reference the xsi namespace (xsi:type="soapenc:string") as well.
      When I try to parse the soap body (extracted from the soap envelope) using JDOM or DOM4J I get a SaxParseException because the soapenv and xsi namespaces are not bound:
      org.xml.sax.SAXParseException: The prefix "soapenv" for attribute "soapenv:encodingStyle" associated with an element type "ns1:sendMessage" is not bound.
      The issue seems to be creating a org.springframework.xml.transform.StaxSource using XMLStreamReader from Axiom payload element and transforming it to a StreamResult.
      I have found a workaround transforming the StaxSource in a JDOMResult instead of a StreamResult.
      The problem is the same as using javax.xml.transform.stax.StAXSource; some Axiom developers have suggested me to use OMSource from a snapshot version (https://issues.apache.org/jira/browse/WSCOMMONS-459) instead of StAXSource.
      The problem is in org.springframework.ws.soap.axiom.Payload#getSource() that uses XMLStreamReader class: namespace declarations is ok if I use OMSource from the snapshot version of axiom (the abstract method getStreamReader() is never used in this solution).

      1. AxiomSoap11MessageFactoryTest.java
        6 kB
        Luca Cavanna
      2. Payload.java
        3 kB
        Luca Cavanna
      3. soapresponse.xml
        0.9 kB
        Luca Cavanna
      4. SpringWsAxiomTestCase.java
        2 kB
        Luca Cavanna

        Issue Links

          Activity

          Hide
          lucacavanna Luca Cavanna added a comment -

          Testcase and soap rpc-encoded.

          Show
          lucacavanna Luca Cavanna added a comment - Testcase and soap rpc-encoded.
          Hide
          lucacavanna Luca Cavanna added a comment -

          Solution using OMSource from axiom snapshot instead of StaxSource.

          Show
          lucacavanna Luca Cavanna added a comment - Solution using OMSource from axiom snapshot instead of StaxSource.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Unfortunately, using the OMSource is not an option for us, since it always expands the OM tree. As a result, it always caches read elements, and breaks the behavior of AxiomSoapMessageFactories whose with payloadcaching set to false.

          I will try to look for another solution.

          Show
          arjen.poutsma Arjen Poutsma added a comment - Unfortunately, using the OMSource is not an option for us, since it always expands the OM tree. As a result, it always caches read elements, and breaks the behavior of AxiomSoapMessageFactories whose with payloadcaching set to false. I will try to look for another solution.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          I am afraid I can't reproduce this.

          Based on the attachments you created, I've added this test case, using this test file. The test case works for me, so I am closing this as 'Cannot Reproduce'.

          Please, let me know if I am missing something.

          Show
          arjen.poutsma Arjen Poutsma added a comment - I am afraid I can't reproduce this. Based on the attachments you created, I've added this test case , using this test file . The test case works for me, so I am closing this as 'Cannot Reproduce'. Please, let me know if I am missing something.
          Hide
          lucacavanna Luca Cavanna added a comment -

          In your testcase you transform message.getEnvelope().getSource() to a StringResult; since the result contains the whole soap envelope, the namespace declarations are ok.
          In my testcase I want to tranform the payload (and not the whole soap envelope) to a StringResult calling message.getPayloadSource(); the result (using version 1.5.6) contains only the soap body.
          Consequently namespace declarations aren't ok and the soap body is not parseable as xml because the soapenv namespace is not bound.
          You have to replace message.getEnvelope().getSource() with message.getPayloadSource() to reproduce my issue.

          Thanks in advance.

          Show
          lucacavanna Luca Cavanna added a comment - In your testcase you transform message.getEnvelope().getSource() to a StringResult; since the result contains the whole soap envelope, the namespace declarations are ok. In my testcase I want to tranform the payload (and not the whole soap envelope) to a StringResult calling message.getPayloadSource(); the result (using version 1.5.6) contains only the soap body. Consequently namespace declarations aren't ok and the soap body is not parseable as xml because the soapenv namespace is not bound. You have to replace message.getEnvelope().getSource() with message.getPayloadSource() to reproduce my issue. Thanks in advance.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Thanks, changing to getPayloadSource() did the trick: the test fails now. I will investigate further.

          Show
          arjen.poutsma Arjen Poutsma added a comment - Thanks, changing to getPayloadSource() did the trick: the test fails now. I will investigate further.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Fixed! Thanks for spotting this, and providing help in the process.

          Show
          arjen.poutsma Arjen Poutsma added a comment - Fixed! Thanks for spotting this, and providing help in the process.
          Hide
          lucacavanna Luca Cavanna added a comment -

          Great! Thank you very much!
          I have tested it with new StaxStreamXmlReader and it's ok.

          I have another little suggestion: in the method testSWS502 of testcase I would differentiate the payload in the initial envelope from the payload expected as the result of the transformation. In the first one you can omit the declaration of the soapenv namespace because it's already present in the envelope, while the second one must contain that declaration. In this way the test shows that the declarations not bounded in body are automatically copied from the envelope to the body.

          I attach my version of the testcase.

          Show
          lucacavanna Luca Cavanna added a comment - Great! Thank you very much! I have tested it with new StaxStreamXmlReader and it's ok. I have another little suggestion: in the method testSWS502 of testcase I would differentiate the payload in the initial envelope from the payload expected as the result of the transformation. In the first one you can omit the declaration of the soapenv namespace because it's already present in the envelope, while the second one must contain that declaration. In this way the test shows that the declarations not bounded in body are automatically copied from the envelope to the body. I attach my version of the testcase.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Thanks, I've updated the test accordingly.

          Show
          arjen.poutsma Arjen Poutsma added a comment - Thanks, I've updated the test accordingly.
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Closing old issues

          Show
          arjen.poutsma Arjen Poutsma added a comment - Closing old issues

            People

            • Assignee:
              arjen.poutsma Arjen Poutsma
              Reporter:
              lucacavanna Luca Cavanna
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: