simple question on jaxb2 unmarshalling

[moores]

I have some client side demos that use 1.0-rc1 WebServiceTemplate for both jaxb1 and jaxb2.
How to I solve the problem with the more strict jaxb2 unmarshaller not understanding what to do with a soap fault? I'm generating my jaxb2 classes with the XSD and the XSD
knows nothing about how to unmarshal faults. It'd be nice, I suppose, to unmarshal
to a real object instead of groking the node as i did with jaxb1.

Here's the exception:

Caused by: javax.xml.bind.UnmarshalException: unexpected element (uri:"http://schemas.xmlsoap.org/soap/envelope/", local:"Fault"). Expected elements are <{http://map
s.real.com/uds/scs}GetShopCartByCartGuidRequest>,<{http://maps.real.com/uds/scs}GetShopCartByCartGuidResponse>,<{http://maps.real.com/uds/scs}GetShopCartByUserKeyReq
uest>,<{http://maps.real.com/uds/scs}GetShopCartByUserKeyResponse>,<{http://maps.real.com/uds/scs}StoreShopCartRequest>,<{http://maps.real.com/uds/scs}StoreShopCartR
esponse>

[Arjen Poutsma]

Now that's weird, because the Unmarshaller is not supposed to unmarshal a Fault returned from a WebService. Instead, faults is handled by a FaultResolver, which by default throws a runtime WebServiceFaultException.
The way the template determines whether something is a fault or not, is by the response code. If it's 500, then it's a fault, which is when the faultresolver is invoked.

[memelet]

I getting back messages with faults, but the http status code is 200, not 500. Hence the fault resolver gets bypassed and I fail unmarshalling.

(This is glassfish providing the ws-stack)

This was working just this morning :-( Surely it must be some form of user error. But after hours and hours I am not getting anywhere.......

[moores]

Thanks for the feedback, I feel like an idiot that I did not look at the response code.
So when I switch over to RC1 i get a 200 instead of the expected 500.


======== Spring-ws 1.0-m3 ==========

HTTP/1.1 500 Internal Server Error

Server: Apache-Coyote/1.1

Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Content-Type: text/xml;charset=utf-8

Content-Length: 714

Date: Wed, 23 May 2007 22:12:05 GMT

Connection: close



<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Client</faultcode>
<faultstring xml:lang="en">Validation error</faultstring>
<detail>
<spring-ws:ValidationError xmlns:spring-ws="http://springframework.org/spring-ws">cvc-pattern-valid: Value 'Bad GUID value' is not facet-valid with respect to pattern '[A-F0-9]{32}' for type 'GuidType'.</spring-ws:ValidationError>
<spring-ws:ValidationError xmlns:spring-ws="http://springframework.org/spring-ws">cvc-type.3.1.3: The value 'Bad GUID value' of element 'ns3:CartGuid' is not valid.</spring-ws:ValidationError>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body></SOAP-ENV:Envelope>

======== Spring-ws 1.0-rc1 ==========

HTTP/1.1 200 OK

Server: Apache-Coyote/1.1

Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2

Content-Type: text/xml;charset=utf-8

Content-Length: 714

Date: Wed, 23 May 2007 22:14:43 GMT



<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header/>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Client</faultcode>
<faultstring xml:lang="en">Validation error</faultstring>
<detail>
<spring-ws:ValidationError xmlns:spring-ws="http://springframework.org/spring-ws">cvc-pattern-valid: Value 'Bad GUID value' is not facet-valid with respect to pattern '[A-F0-9]{32}' for type 'GuidType'.</spring-ws:ValidationError>
<spring-ws:ValidationError xmlns:spring-ws="http://springframework.org/spring-ws">cvc-type.3.1.3: The value 'Bad GUID value' of element 'ns2:CartGuid' is not valid.</spring-ws:ValidationError>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body></SOAP-ENV:Envelope>

[moores]

So why would the new RC1 return a 200? in 1.0-m3 i get a 500 and my FaultResolver
gets called like it should...
--Michael

Now that's weird, because the Unmarshaller is not supposed to unmarshal a Fault returned from a WebService. Instead, faults is handled by a FaultResolver, which by default throws a runtime WebServiceFaultException.
The way the template determines whether something is a fault or not, is by the response code. If it's 500, then it's a fault, which is when the faultresolver is invoked.

[memelet]

Interesting. I also just switch to RC1. I though I was having a glassfish issue.

Well, here is a dirty hack that you can use to workaround if you are using WebServiceTemplate. Change WST.hasFault(..)

from:

    private boolean hasFault(WebServiceConnection connection, WebServiceMessage response) throws IOException {
        if (connection instanceof FaultAwareWebServiceConnection) {
            return ((FaultAwareWebServiceConnection) connection).hasFault();
        }
        else {
            return response.hasFault();
        }
    }

to:

    private boolean hasFault(WebServiceConnection connection, WebServiceMessage response) throws IOException {
        if (connection instanceof FaultAwareWebServiceConnection) {
            return ((FaultAwareWebServiceConnection) connection).hasFault() || response.hasFault();
        }
        else {
            return response.hasFault();
        }
    }

You can't sublcass because hasFault is private. And @Aspect does not support privileged aspects. So the only real solution is to either mod the class and rebuild spring-ws, or, what I do, is add the modified class into my project keeping the spring package and ensure that my classes are ordered prior to spring-ws.

Arjen, is this a known issue in spring-ws rc1? Not really a problem with spring-ws but really elsewhere? I couldn't find a related jira issue, but I'm off to sail down the Chesapeake for a long weekend so I won't be filing one till Tuesday.

cheers!!

[Arjen Poutsma]

Hmm, this looks like a bug, and quite a critical one, too. A SOAP Fault needs to set the response code to 500, according to the WS-I spec. I've created http://opensource.atlassian.com/proj...browse/SWS-128, which I'll fix asap. I'll try and create a snapshot that fixes it this weekend. Obviously, it will be fixed in RC2.

I'm sorry about this, especially since it used to work in m3.

[moores]

Yea I'm kinda blocked cause I started using some of the changes in RC1 which are critical for me. Does it makes sense to just to redeploy RC1 with the fix?

Hmm, this looks like a bug, and quite a critical one, too. A SOAP Fault needs to set the response code to 500, according to the WS-I spec. I've created http://opensource.atlassian.com/proj...browse/SWS-128, which I'll fix asap. I'll try and create a snapshot that fixes it this weekend. Obviously, it will be fixed in RC2.

I'm sorry about this, especially since it used to work in m3.

[Arjen Poutsma]

Yea I'm kinda blocked cause I started using some of the changes in RC1 which are critical for me. Does it makes sense to just to redeploy RC1 with the fix?

I have found the bug, and fixed it. Creating a new RC release is something I want to defer a little longer, so that more issues found in RC1 can be fixed. Making a release is something which takes me an entire day, and I prefer to use that time for fixing other bugs. The RC2 release is currently planned for the 19th of June, though I think I will release it a week or two earlier, so that you don't have to wait too long.

In the mean time, you can use an RC2 snapshot. This zipfile contains the fix, and if you're using Maven2, you just need to follow the steps described here.

[moores]

Thanks Arjen.
When will you create a spring-ws-1.0-rc2 branch?
--Michael

I have found the bug, and fixed it. Creating a new RC release is something I want to defer a little longer, so that more issues found in RC1 can be fixed. Making a release is something which takes me an entire day, and I prefer to use that time for fixing other bugs. The RC2 release is currently planned for the 19th of June, though I think I will release it a week or two earlier, so that you don't have to wait too long.

In the mean time, you can use an RC2 snapshot. This zipfile contains the fix, and if you're using Maven2, you just need to follow the steps described here.