Soap envelope rpc-encoded namespace issue [SWS-502]

[gregturn]

Luca Cavanna opened SWS-502 and commented

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).

---

Affects: 1.5.6

Attachments:

• AxiomSoap11MessageFactoryTest.java (6.01 kB)
• Payload.java (2.54 kB)
• soapresponse.xml (916 bytes)
• SpringWsAxiomTestCase.java (2.09 kB)

Issue Links:

• Namespace prefix in attribute value not resolved correctly [SWS-509] #639 Namespace prefix in attribute value not resolved correctly
  ("is duplicated by")

Referenced from: commits a50f38a, 48a1767

[gregturn]

Luca Cavanna commented

Testcase and soap rpc-encoded.

[gregturn]

Luca Cavanna commented

Solution using OMSource from axiom snapshot instead of StaxSource.

[gregturn]

Arjen Poutsma commented

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.

[gregturn]

Arjen Poutsma commented

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.

[gregturn]

Luca Cavanna commented

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.

[gregturn]

Arjen Poutsma commented

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

[gregturn]

Arjen Poutsma commented

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

[gregturn]

Luca Cavanna commented

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.

[gregturn]

Arjen Poutsma commented

Thanks, I've updated the test accordingly.

[gregturn]

Arjen Poutsma commented

Closing old issues