CLONE -Namespace prefix in attribute value not resolved correctly [SWS-523]

[gregturn]

Lukas Krecan opened SWS-523 and commented

I have following SOAP request.

 
<soapenv:Envelope  xmlns:ns="http://schemas.qqq.com/wsdl/spi/profile/1.0" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header/>
   <soapenv:Body>
      <ns:getRights> 
            <ns:customerCredential xsi:type="ns:CustomerCredentialMsisdn">
               <ns:msisdn>420123456789</ns:msisdn>
            </ns:customerCredential>
      </ns:getRights>
   </soapenv:Body>
</soapenv:Envelope>

When umarshalling is called only the payload is passed to the unmarshaller. So DOM equivalent of following is used

 
<ns:getRights> 
            <ns:customerCredential xsi:type="ns:CustomerCredentialMsisdn">
               <ns:msisdn>420123456789</ns:msisdn>
            </ns:customerCredential>
</ns:getRights>

Please note that namespace prefix ns is not defined. Usually this is not a problem since in DOM namespaces are already resolved. There is one exception - attribute value. When XmlBeans try to unmarshall the element, they are not able to resolve the namespace and do not work correctly. I assume that Spring-WS should somehow take this situation into account.

If following request is used (the only difference is position of ns prefix declaration) everything works fine

 
<soapenv:Envelope  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soapenv:Header/>
   <soapenv:Body>
      <ns:getRights xmlns:ns="http://schemas.qqq.com/wsdl/spi/profile/1.0"> 
            <ns:customerCredential xsi:type="ns:CustomerCredentialMsisdn">
               <ns:msisdn>420123456789</ns:msisdn>
            </ns:customerCredential>
      </ns:getRights>
   </soapenv:Body>
</soapenv:Envelope>

---

Affects: 1.5.6, 1.5.7

Reference URL: http://forum.springsource.org/showthread.php?t=71673

Attachments:

• test-ws-1.0-SNAPSHOT-src.zip (5.61 kB)
• test-ws-1.0-SNAPSHOT-src.zip (5.57 kB)

Issue Links:

• Namespace prefix in attribute value not resolved correctly [SWS-509] #639 Namespace prefix in attribute value not resolved correctly

• Payload unmarshalling fails when soap body element attribute references namespace declared in envelope [SWS-565] #686 Payload unmarshalling fails when soap body element attribute references namespace declared in envelope

1 votes, 0 watchers

[gregturn]

Lukas Krecan commented

Clone of #639 which in my opinion was not resolved in 1.5.7

[gregturn]

Lukas Krecan commented

Project with tests. Two valid equivalent SOAP request, one fails, the other one succeeds.

[gregturn]

Lukas Krecan commented

Test project fixed

[gregturn]

koen janssens commented

Another strange effect. If the namespace is defined in both the envelope and the body, the namespace is not passed to the marshaller.

So:

<soapenv:Envelope xmlns:ns="http://schemas.qqq.com/wsdl/spi/profile/1.0" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
soapenv:Header/
soapenv:Body
<ns:getRights xmlns:ns="http://schemas.qqq.com/wsdl/spi/profile/1.0">
<ns:customerCredential xsi:type="ns:CustomerCredentialMsisdn">
ns:msisdn420123456789</ns:msisdn>
</ns:customerCredential>
</ns:getRights>
</soapenv:Body>
</soapenv:Envelope>

Does not work either. Apparantly, the namespace is automatically removed from the body if it is already define in the envelope.

[gregturn]

Lukas Krecan commented

JAXB marshaller works in both cases

[gregturn]

Arjen Poutsma commented

I've been hacking this for a couple of days now, but I can't find a satisfactory solution. So I'm closing as Won't Fix for now.

The problem here seems to be that XMLBeans will not query the DOM tree for the resolution of the namespace of the attribute value. In the end, what we're doing in the SAAJ message to return the payload source simply comes down to:

SOAPMessage saajMessage = ...
Element element = saajMessage.getSoapBody();
return new DOMSource(element);

We don't manipulate the DOM tree at all for getPayloadSource(), since that would result in a lot of overhead which is mostly unnecessary: all the necessary namespace information can be retrieved through querying the DOM tree. The problem described here is that XMLBeans does not do that, which is more a XMLBeans issue than a Spring-WS one.

[gregturn]

Lukas Krecan commented

Issue created in XMLBeans project JIRA https://issues.apache.org/jira/browse/XMLBEANS-427

[gregturn]

Arjen Poutsma commented

Closing old issues