Thanks for the feedback Richard. I have also been experimenting with exceptions the last couple of days. Im still feeling my way through AXIS. We were using GLUE and no GLUE types were exposed in the client proxy classes. I guess that GLUE is a little more mature.
You are right about the source/cause of the exception being hidden and this being awkward. For example, there are a number of times that I have been getting InvocationTargetExceptions with no source exception. So its difficult to trace the exact problem. It would be good to have the remote stack trace.
However I am now getting my custom exception transported to the client. Even with its error code member variable. :-)
Another question... In my originally specified exception it derived from Exception and it had a cnstr that passed a String (message) up to the Exception class. But after running Java2WSDL and WSDL2Java this cnstr has gone. So where would I set the string message that will be passed up to the Exception class?
Hansen, Richard wrote:
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:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2003 8:30 AM To: [EMAIL PROTECTED] 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.
