Daniel Kulp wrote > On Sep 14, 2012, at 7:32 AM, Jens wrote: >> Hi, >> >> I'm using CXF in combination with Apache Camel to bridge between XML/MQ >> and >> SOAP/HTTP and back. >> >> When I get a SOAP fault back from the service provider the XML >> representation generated by CXF is incomplete. >> >> For example, this fault (XML escaped to get it through nabble) >> >> [?xml version="1.0" encoding="UTF-8"?] >> [env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/";] >> [env:Body] >> [env:Fault] >> [faultcode]0x0012345[/faultcode] >> [faultstring]Rejected.[/faultstring] >> [detail] >> [service]SERVICE_WS[/service] >> [transaction]123456789[/transaction] >> [operation]/services/ws/test[/operation] >> [result status="ERROR"][message]error message[/message][/result] >> [/detail] >> [/env:Fault] >> [/env:Body] >> [/env:Envelope] > > I'm curious how this is represented in the WSDL as it's likely not a > WSI-BP compliant service (or a valid WSDL for that matter). > > According to: > http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_soap:fault > > a SOAP fault in the wsdl "MUST have a single part." Since faults are > Doc/Literal, they must be specified by element (not type) parts. Thus, a > fault should be describable with a single element in the detail. It's > quite likely that parts of CXF (and the Camel/CXF component) make general > assumptions that the SOAP messages and such would meet WSI-BP and the WSDL > spec and thus only examine and pass on the first element of the detail.
Hi Dan, the fault is implicit in this case and therefore not represented in the WSDL at all. I'll see if I can make them refactor the service to be spec-compliant. I am not hopeful, though. Anyway, thanks for the hint, Jens -- View this message in context: http://cxf.547215.n5.nabble.com/Faults-in-XML-binding-tp5713940p5714283.html Sent from the cxf-user mailing list archive at Nabble.com.
