You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by mf...@gmail.com on 2012/05/10 09:43:55 UTC
Axis2 1.5.3 - WSDL2Java client stub - dealing with fault data outside
of Detail element
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?
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
Re: Axis2 1.5.3 - WSDL2Java client stub - dealing with fault data
outside of Detail element
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
On Mon, Jun 18, 2012 at 10:32 AM, <mf...@gmail.com> wrote:
> 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.
>
This parameter is used by axis2 server side to get the root cause of an
error and set it as the fault reason. But you said that you are trying to
consume a third party service, which in this case this you are on the
client side. So i'm afraid this parameter will not be helpful for your case.
But i found that this is a known bug and was fixed with axis2 1.6.2 release
[1]. Can you try with 1.6.2 and see whether you can overcome this?
Thanks,
Kishanthan.
[1] https://issues.apache.org/jira/browse/AXIS2-5265
>
> Thanks
> Matt
>
>
>
> On 17 June 2012 17:43, Kishanthan Thangarajah <ks...@gmail.com>wrote:
>
>>
>>
>> On Thu, May 10, 2012 at 1:13 PM, <mf...@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
>>>
>>
>>
>
Re: Axis2 1.5.3 - WSDL2Java client stub - dealing with fault data
outside of Detail element
Posted by mf...@gmail.com.
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 <ks...@gmail.com> wrote:
>
>
> On Thu, May 10, 2012 at 1:13 PM, <mf...@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
>>
>
>
Re: Axis2 1.5.3 - WSDL2Java client stub - dealing with fault data
outside of Detail element
Posted by Kishanthan Thangarajah <ks...@gmail.com>.
On Thu, May 10, 2012 at 1:13 PM, <mf...@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
>