How can I handle Castor unmarshaling of SOAP messa

Question

I am developing a contract-first web service based on Spring-WS. I'm relying on Castor marshaling, and I have run into the following issue.

Requests are being accepted when the "xmlns" namespace is defined in the Envelope tag, such as:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
                      xmlns="http://www.mycompany.com/MyService/schemas">
  <soap:Header/>
  <soap:Body>
    <doPlaceHoldRequest>
      <hold>
        <accountInfo>
          <accountNumber>123456789</accountNumber>
        </accountInfo>
        <extended>false</extended>
        <afterHours>false</afterHours>
        <amountSavings>1.00</amountSavings>
        <amountChecking>0.00</amountChecking>
      </hold>
    </doPlaceHoldRequest>
  </soap:Body>
</soap:Envelope>

However, both .NET and Java clients generated from the .wsdl provided by Spring-WS (which was generated from a XSD), form their requests in the following manner:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header/>
  <soap:Body>
    <doPlaceHoldRequest 
                xmlns="http://www.mycompany.com/MyService/schemas">
      <hold>
        <accountInfo>
          <accountNumber>123456789</accountNumber>
        </accountInfo>
        <extended>false</extended>
        <afterHours>false</afterHours>
        <amountSavings>1.00</amountSavings>
        <amountChecking>0.00</amountChecking>
      </hold>
    </doPlaceHoldRequest>
  </soap:Body>
</soap:Envelope>

Which results in an Unmarshalling Exception being thrown by Castor. How do I get Castor to recognize these messages as valid? Could my WSDL (or the XSD I used to autogenerate it) be wrong?

Answer 1

IF u see this blog i think will never go to other webservices :) http://springkbase.blogspot.com/2009/06/spring-webservice-with-castor.html

Answer 2

I ran into this problem over and over again with my first Spring-WS/Castor web service. As far as I can tell, somewhere along the line some component extracts the payload in a non-namespace-aware way. In other words, a node like doPlaceHoldRequest becomes the root of an XML document without inheriting the top-level namespace declaration, and in the two cases above, that leads to one that is in the namespace you want, and one that is not - so one validates fine against your schema, and the other does not.

The best solution seems to be to cover all the bases. Make your XSD have elementFormDefault="qualified", to require all your elements to be in a namespace. Then specify an ns-uri and an ns-prefix in every map-to element in your Castor mapping. The result is a little heavier, with all the namespace prefixes, but it seems to make it a lot less fragile when it comes to lazy clients and undocumented behavior in server components.

JAX-WS return empty lists makes a good point, too. org.springframework.ws.soap.server.endpoint.interceptor.PayloadValidatingInterceptor is worth having to validate what comes in and out.