[SWS-523] CLONE -Namespace prefix in attribute value not resolved correctly Created: 01/Jun/09  Updated: 04/May/12  Resolved: 24/Aug/09

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

Type: Bug Priority: Major
Reporter: Lukas Krecan Assignee: Arjen Poutsma
Resolution: Won't Fix Votes: 1
Labels: None
Remaining Estimate: 0d
Time Spent: 5d 1h 11m
Original Estimate: Not Specified

Attachments: Zip Archive test-ws-1.0-SNAPSHOT-src.zip     Zip Archive test-ws-1.0-SNAPSHOT-src.zip    
Issue Links:
Related
is related to SWS-509 Namespace prefix in attribute value n... Closed
is related to SWS-565 Payload unmarshalling fails when soap... Closed
Reference URL: http://forum.springsource.org/showthread.php?t=71673

 Description   

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>



 Comments   
Comment by Lukas Krecan [ 01/Jun/09 ]

Clone of SWS-509 which in my opinion was not resolved in 1.5.7

Comment by Lukas Krecan [ 01/Jun/09 ]

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

Comment by Lukas Krecan [ 01/Jun/09 ]

Test project fixed

Comment by koen janssens [ 18/Jun/09 ]

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:msisdn>420123456789</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.

Comment by Lukas Krecan [ 20/Jul/09 ]

JAXB marshaller works in both cases

Comment by Arjen Poutsma [ 24/Aug/09 ]

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.

Comment by Lukas Krecan [ 04/Jan/10 ]

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

Comment by Arjen Poutsma [ 04/May/12 ]

Closing old issues

Generated at Mon Dec 18 11:04:00 UTC 2017 using JIRA 6.4.14#64029-sha1:ae256fe0fbb912241490ff1cecfb323ea0905ca5.