My workaround for this is to introduce a saxon proxy for all of the partner links that might result in a fault. I'd prefer some declarative way of handling this in ODE but it's very easy to implement and I assume very low cost since I only need to do transforms when a fault is thrown.
On 2/4/09 5:45 PM, "Ford, Mark" <[email protected]> wrote: I've run into an issue where a SOAP:Fault with multiple detail elements is causing the fault handling in my process to fail. This looks like a servicemix issue more than an ODE issue but I'm curious how other developers are dealing with it. ODE correctly matches the fault to the intended catch element. This catch is defined with the appropriate fault WSDL message and name. The problem arises when trying to copy values from this fault variable since the underlying XML doesn't match the definition of the variable. For example: <multiple-details> <ns1:myFault>...</ns1:myFault> <ns2:exceptionName/> <ns2:hostname/> </multiple-details> Vs <ns1:myFault>...</ns1:myFault> If I tweak the service I'm invoking to reply with a single detail then everything works fine. I won't always be in control of the services I'm invoking so it's possible I could run into this issue in the future if I end up invoking other axis services. Is there a way to have ODE automatically unwrap this fault for me so I don't have to deal with the multiple-details element? The fact that the correct catch block executed indicates that ODE is somehow accounting for this multiple-details element within the fault matching logic so perhaps there's a way to have it unwrap it and discard all but the first detail. -- Mark Ford MIT Lincoln Laboratory 244 Wood Street Lexington MA 02420 (781) 981-1843
