Thanks for your reply Kishanthan. Unfortunately, setting that parameter before calling a web service from the client stub doesn't change anything. The same web service-specific exception is still matched/generated and sent back from the stub. The AxisFault received by the client stub is the correct error - however the stub matches the detail with the exceptions provided for by the WSDL and sends back the match. I don't think there is any way around this behaviour besides modifying the stub.
Please le me know if I have misunderstood your response. Thanks Matt On 17 June 2012 17:43, Kishanthan Thangarajah <kshanth2...@gmail.com> wrote: > > > On Thu, May 10, 2012 at 1:13 PM, <mfle...@gmail.com> wrote: > >> Hi all >> >> I have generated a client stub to call a 3rd party web service using >> Wsdl2Java. The provided WSDL (and XSDs imported it) includes a number of >> faults which are generated and returned by Axis2 as exceptions (all as per >> usual so far). >> >> However, the actual Soap message returned by the web service when a fault >> is encountered also includes some handy information outside of the Detail >> element, namely in the Reason element. An example is below: >> >> <s:Body> >> <s:Fault> >> <s:Code> >> <s:Value>s:Sender</s:Value> >> </s:Code> >> <s:Reason> >> <s:Text xml:lang="en-AU">The RegistrationEndDateTime has an invalid >> datetime format. Check that it does not specify timezone information or >> have more than seconds precision.</s:Text> >> </s:Reason> >> <s:Detail> >> <InvalidDateTimeFormatFaultDetail xmlns="http://schemas.xyz/faults"; >> xmlns:i="http://www.w3.org/2001/XMLSchema-instance";> >> <ErrorNumber>50016</ErrorNumber> >> >> <ErrorReferenceId>7f2f1085-9c7e-44a8-b1b7-2a995d0a4e0f</ErrorReferenceId> >> >> <RequestProcessedByEnvironment>Discovery</RequestProcessedByEnvironment> >> <ElementName>RegistrationEndDateTime</ElementName> >> </InvalidDateTimeFormatFaultDetail> >> </s:Detail> >> </s:Fault> >> </s:Body> >> >> The InvalidDateTimeFormatFaultDetail is what is defined in the WSDL/XSD. >> Axis2 only generates this detail bit as the exception - the rest is >> abandoned. I therefore don't have access to the other soap fault fields, >> such as Code and Reason. >> >> I had a look at the stub, and can see where it catches an AxisFault, >> pulls out its Detail element, matches it up with one of the defined >> exceptions from the WSDL, and populates and throws an instance of the WSDL >> exception with the details from the Detail element. >> >> Is there any way to work-around this so I can get access to the Reason >> data? >> > > There is a parameter in axis2.xml namely > "DrillDownToRootCauseForFaultReason", which is set to false by default. You > can set that to true to get the fault reason. > > Thanks, > Kishanthan. > >> >> One thing I did try was generating the stub with a different exception >> base class (using -ebc) of org.apache.axis2.AxisFault. This actually ends >> up providing the info I need, mainly because in the stub it gets an >> instantiation exception when trying to instantiate the WSDL exception and >> cast it to java.lang.Exception. The stub then throws the original >> AxisFault. This provides me all the data I want, but it seems kind of >> wrong to do it this way (i.e. getting the data through the fact the stub >> can't process the exception properly :-) ). Thoughts anyone? >> >> Thanks heaps >> Matt >> > >
