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

          lucacavanna Luca Cavanna created issue -
          Hide
          lucacavanna Luca Cavanna added a comment -

          Testcase and soap rpc-encoded.

          Show
          lucacavanna Luca Cavanna added a comment - Testcase and soap rpc-encoded.
          lucacavanna Luca Cavanna made changes -
          Field Original Value New Value
          Attachment SpringWsAxiomTestCase.java [ 15339 ]
          Attachment soapresponse.xml [ 15340 ]
          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.
          lucacavanna Luca Cavanna made changes -
          Attachment Payload.java [ 15341 ]
          arjen.poutsma Arjen Poutsma made changes -
          Fix Version/s 1.5.7 [ 11173 ]
          arjen.poutsma Arjen Poutsma made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          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.
          arjen.poutsma Arjen Poutsma made changes -
          Resolution Cannot Reproduce [ 5 ]
          Status In Progress [ 3 ] Resolved [ 5 ]
          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.
          arjen.poutsma Arjen Poutsma made changes -
          Status Resolved [ 5 ] Reopened [ 4 ]
          Resolution Cannot Reproduce [ 5 ]
          arjen.poutsma Arjen Poutsma made changes -
          Status Reopened [ 4 ] In Progress [ 3 ]
          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.
          arjen.poutsma Arjen Poutsma made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          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.
          lucacavanna Luca Cavanna made changes -
          Attachment AxiomSoap11MessageFactoryTest.java [ 15398 ]
          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.
          arjen.poutsma Arjen Poutsma made changes -
          Link This issue is duplicated by SWS-509 [ SWS-509 ]
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Closing old issues

          Show
          arjen.poutsma Arjen Poutsma added a comment - Closing old issues
          arjen.poutsma Arjen Poutsma made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open In Progress In Progress
          24d 4h 15m 1 Arjen Poutsma 18/May/09 1:28 AM
          Resolved Resolved Reopened Reopened
          17h 50m 1 Arjen Poutsma 18/May/09 7:34 PM
          Reopened Reopened In Progress In Progress
          37m 2s 1 Arjen Poutsma 18/May/09 8:11 PM
          In Progress In Progress Resolved Resolved
          29m 22s 2 Arjen Poutsma 18/May/09 8:24 PM
          Resolved Resolved Closed Closed
          1081d 10h 38m 1 Arjen Poutsma 04/May/12 7:03 AM

            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: