axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hansen, Richard" <richard.han...@thomson.com>
Subject RE: Exceptions mapped to AxisFault using WSDL to Java
Date Wed, 20 Aug 2003 13:12:03 GMT
I suppose it does that because Call.invoke() only throws AxisFaults. If you
throw an exception without defining it to axis then axis wraps it in a
AxisFault. If you define application specific exceptions they seem to need
descend from AxisFault so they get serialized. If you don't want to see any
"AxisFault" on the clientside, then you proabably need to configure axis to
handle the application specific exceptions that you throw. Of course those
exceptions still need to subclass AxisFault.

I did a bunch of experimenting to understand how axis handles excpetions and
faults and here is what I found out. Hope this helps.

Rick Hansen


- For all practical purposes a client programmer can treat Axis as if it
only throws 
  org.apache.axis.AxisFault exceptions. 
- Axis does not throw javax.xml.rpc.soap.SOAPFaultException. Axis never
creates a SOAPFaultException itself. However, since SOAPFaultException is
unchecked, one could leak through if thrown by a handler or service
implementation. 
- The invoke methods that are likely to be called by a client programmer
(the ones inherited from javax.xml.rpc.Call) return either a service
specific exception or org.apache.axis.AxisFault. 
- A service implementation can throw any type of exception.
- Axis faults thrown by a service implementation are returned to the client
just as thrown. 
- A non AxisFault thrown by a service implementation but not configured as a
service specific exception will be wrapped in an AxisFault on the client. A
faultCode of Server.userException and a local stack trace will be included
in the Axisfault. This is not the most useful thing that could happen as it
tends to hide the source/cuase of the exception. The fault string included
represents the original exception.
- Axis must be configured to handle service specific exceptions and recreate
them on the client. 
- Service specific exceptions can can be configured using either parameters
in the wsdd deployment file or using calls to
org.apache.axis.description.OperationDesc in the service stubs and
skeletons. 
- Service specific exceptions must subclass org.apache.axis.AxisFault. 
- The WSDL to Java tools will create service specific exceptions that are
defined in a wsdl file and create the required configuration code in the
stubs and skeletons generated.

> -----Original Message-----
> From: Stuart Barlow [mailto:sbarlow@peopledoc.com]
> Sent: Tuesday, August 19, 2003 8:30 AM
> To: axis-user@ws.apache.org
> Subject: Exceptions mapped to AxisFault using WSDL to Java
> 
> 
> When I have an interface and use Java2WSDL followed by WSDL2Java
> I end up with AXIS types in my interface. This means that AXIS
> types are now polluting exposed in the client. Exceptions are
> derived from AxisFault
> 
> So I have to provide another wrapper around the client interface
> for client apps to use, that does not have AXIS types.
> 
> Does WSDL2Java have to use AXIS types in produced interfaces?
> 
> Ta.
> Stuart.
> 

Mime
View raw message