[SWS-502] Soap envelope rpc-encoded namespace issue Created: 23/Apr/09  Updated: 04/May/12  Resolved: 18/May/09

Status: Closed
Project: Spring Web Services
Component/s: Core, XML
Affects Version/s: 1.5.6
Fix Version/s: 1.5.7

Type: Bug Priority: Major
Reporter: Luca Cavanna Assignee: Arjen Poutsma
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Java Source File AxiomSoap11MessageFactoryTest.java     Java Source File Payload.java     Java Source File SpringWsAxiomTestCase.java     XML File soapresponse.xml    
Issue Links:
Duplicate
is duplicated by SWS-509 Namespace prefix in attribute value n... Closed

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



 Comments   
Comment by Luca Cavanna [ 23/Apr/09 ]

Testcase and soap rpc-encoded.

Comment by Luca Cavanna [ 23/Apr/09 ]

Solution using OMSource from axiom snapshot instead of StaxSource.

Comment by Arjen Poutsma [ 18/May/09 ]

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.

Comment by Arjen Poutsma [ 18/May/09 ]

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.

Comment by Luca Cavanna [ 18/May/09 ]

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.

Comment by Arjen Poutsma [ 18/May/09 ]

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

Comment by Arjen Poutsma [ 18/May/09 ]

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

Comment by Luca Cavanna [ 18/May/09 ]

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.

Comment by Arjen Poutsma [ 18/May/09 ]

Thanks, I've updated the test accordingly.

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Wed Dec 13 16:48:53 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.