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

          dart0 Lukas Krecan created issue -
          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.
          dart0 Lukas Krecan made changes -
          Field Original Value New Value
          Attachment test-ws-1.0-SNAPSHOT-src.zip [ 15440 ]
          arjen.poutsma Arjen Poutsma made changes -
          Link This issue is related to SWS-509 [ SWS-509 ]
          arjen.poutsma Arjen Poutsma made changes -
          Affects Version/s 1.5.7 [ 11173 ]
          Fix Version/s 1.5.8 [ 11236 ]
          Fix Version/s 1.5.7 [ 11173 ]
          Hide
          dart0 Lukas Krecan added a comment -

          Test project fixed

          Show
          dart0 Lukas Krecan added a comment - Test project fixed
          dart0 Lukas Krecan made changes -
          Attachment test-ws-1.0-SNAPSHOT-src.zip [ 15441 ]
          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
          arjen.poutsma Arjen Poutsma made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          arjen.poutsma Arjen Poutsma logged work - 20/Aug/09 9:06 PM
          • Time Spent:
            2.55h
             
            <No comment>
          arjen.poutsma Arjen Poutsma made changes -
          Remaining Estimate 0d [ 0 ]
          Time Spent 2.55h [ 9180 ]
          arjen.poutsma Arjen Poutsma made changes -
          Status In Progress [ 3 ] Open [ 1 ]
          arjen.poutsma Arjen Poutsma made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          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.
          arjen.poutsma Arjen Poutsma made changes -
          Resolution Won't Fix [ 2 ]
          Status In Progress [ 3 ] Resolved [ 5 ]
          arjen.poutsma Arjen Poutsma logged work - 24/Aug/09 8:15 PM
          • Time Spent:
            4d
             
            <No comment>
          arjen.poutsma Arjen Poutsma made changes -
          Time Spent 2.55h [ 9180 ] 4d 2.55h [ 124380 ]
          arjen.poutsma Arjen Poutsma made changes -
          Link This issue is related to SWS-565 [ SWS-565 ]
          arjen.poutsma Arjen Poutsma logged work - 21/Sep/09 9:15 PM
          • Time Spent:
            6h 38m
             
            <No comment>
          arjen.poutsma Arjen Poutsma made changes -
          Time Spent 4d 2.55h [ 124380 ] 5d 1h 11m [ 148260 ]
          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
          arjen.poutsma Arjen Poutsma made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          In Progress In Progress Open Open
          1d 58m 1 Arjen Poutsma 20/Aug/09 9:07 PM
          Open Open In Progress In Progress
          78d 23h 22m 2 Arjen Poutsma 20/Aug/09 11:46 PM
          In Progress In Progress Resolved Resolved
          3d 20h 28m 1 Arjen Poutsma 24/Aug/09 8:14 PM
          Resolved Resolved Closed Closed
          983d 10h 48m 1 Arjen Poutsma 04/May/12 7:03 AM

            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