Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-523

CLONE -Namespace prefix in attribute value not resolved correctly

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: 1.5.6, 1.5.7
    • Fix Version/s: 1.5.8
    • Component/s: Core
    • Labels:
      None

      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>

        Issue Links

          Activity

          Hide
          dart0 Lukas Krecan added a comment -

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

          Show
          dart0 Lukas Krecan added a comment - Clone of SWS-509 which in my opinion was not resolved in 1.5.7
          Hide
          dart0 Lukas Krecan added a comment -

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

          Show
          dart0 Lukas Krecan added a comment - Project with tests. Two valid equivalent SOAP request, one fails, the other one succeeds.
          Hide
          dart0 Lukas Krecan added a comment -

          Test project fixed

          Show
          dart0 Lukas Krecan added a comment - Test project fixed
          Hide
          janssk1 koen janssens added a comment -

          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.

          Show
          janssk1 koen janssens added a comment - 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.
          Hide
          dart0 Lukas Krecan added a comment -

          JAXB marshaller works in both cases

          Show
          dart0 Lukas Krecan added a comment - JAXB marshaller works in both cases
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          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.

          Show
          arjen.poutsma Arjen Poutsma added a comment - 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.
          Hide
          dart0 Lukas Krecan added a comment -

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

          Show
          dart0 Lukas Krecan added a comment - Issue created in XMLBeans project JIRA https://issues.apache.org/jira/browse/XMLBEANS-427
          Hide
          arjen.poutsma Arjen Poutsma added a comment -

          Closing old issues

          Show
          arjen.poutsma Arjen Poutsma added a comment - Closing old issues

            People

            • Assignee:
              arjen.poutsma Arjen Poutsma
              Reporter:
              dart0 Lukas Krecan
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0d
                0d
                Logged:
                Time Spent - 5d 1h 11m
                5d 1h 11m