Announcement Announcement Module
Collapse
No announcement yet.
simple question on jaxb2 unmarshalling Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • simple question on jaxb2 unmarshalling

    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>

  • #2
    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.

    Comment


    • #3
      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.......

      Comment


      • #4
        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>

        Comment


        • #5
          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

          Originally posted by Arjen Poutsma View Post
          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.

          Comment


          • #6
            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:
            Code:
                private boolean hasFault(WebServiceConnection connection, WebServiceMessage response) throws IOException {
                    if (connection instanceof FaultAwareWebServiceConnection) {
                        return ((FaultAwareWebServiceConnection) connection).hasFault();
                    }
                    else {
                        return response.hasFault();
                    }
                }
            to:

            Code:
                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!!
            Last edited by memelet; May 23rd, 2007, 07:45 PM.

            Comment


            • #7
              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.
              Last edited by Arjen Poutsma; May 24th, 2007, 09:07 AM.

              Comment


              • #8
                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?

                Originally posted by Arjen Poutsma View Post
                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.

                Comment


                • #9
                  Originally posted by moores View Post
                  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.

                  Comment


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

                    Originally posted by Arjen Poutsma View Post
                    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.

                    Comment


                    • #11
                      I won't create a separate branch for RC2; the HEAD branch is RC2 now. Branching can be a serious pain, so I think I will postpone it as long as possible.

                      Comment


                      • #12
                        How to revert this? I mean I want spring to return status code 200 because flex/flash is stupid to understand other codes.

                        That zip file is no longer available.

                        Comment

                        Working...
                        X