axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (AXIS-1605) SOAPFaultException should be throw instead of AxisFault to be compliant with JAX-RPC 1.1
Date Wed, 13 Oct 2004 22:11:51 GMT
The following comment has been added to this issue:

     Author: Steve Loughran
    Created: Wed, 13 Oct 2004 3:11 PM

Looking at the scope of things, its clear that SOAPFaultException is new for SAAJ; meaning
it is new in this version of Axis. I think we could consider somehow merging AxisFault so
it is an implementation of SOAPFaultElement, but this is not going to happen in Axis1.2; its
too late in the game, and there is lots of risks of regression.

As it stands, Axis is technically compliant by throwing AxisFault stuff, but it does limit
your code's ability to run against other stacks. 

Returning to your underlying problem -inadequate diagnostics on faults. 

When you run against a production server you are not going to get a stack trace, whether you
know the names of the Axis elements or not. You should see something on the log of the app
however; Axis logs any unexpected runtime faults, and you can configure the logging to log
all faults (in detail) by setting the relevant log level in the log4J configuration of your


I am going to mark this as an enhancement, not a defect. 
View this comment:

View the issue:

Here is an overview of the issue:
        Key: AXIS-1605
    Summary: SOAPFaultException should be throw instead of AxisFault to be compliant with
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Axis
             1.2 Beta

   Reporter: S├ębastien Tardif

    Created: Tue, 12 Oct 2004 9:35 AM
    Updated: Wed, 13 Oct 2004 3:11 PM
Environment: Axis 9/23/2004

SOAPFaultException should be throw instead of AxisFault to be compliant with JAX-RPC 1.1.

Right now as a Axis client of a webservices implemented with Axis I receive an AxisFault instead
of a SOAPFaultException.

The JAX-RPC 1.1 said:

>From 4.3.6:
A wsdl:fault is mapped to either a java.rmi.RemoteException (or its subclass),
service specific Java exception (described later in this section) or a javax.xml.rpc.
soap.SOAPFaultException. Refer to the section 6.5, "SOAP Fault" for more details on
the Java mapping of a WSDL fault based on the SOAP binding.
Refer to the section 14.3.6, "Mapping of Remote Exceptions" for the mapping between
the standard SOAP faults [5] and the java.rmi.RemoteException.
Service Specific Exception
A service specific Java exception (mapped from a wsdl:fault and the corresponding
wsdl:message) extends the class java.lang.Exception directly or indirectly.
The single message part in the wsdl:message (referenced from the wsdl:fault
element) may be either a type or an element. If the former, it can be either a
xsd:complexType or a simple XML type.
Each element inside the xsd:complexType is mapped to a getter method and a
parameter in the constructor of the Java exception. Mapping of these elements follows
the standard XML to Java type mapping. The name of the Java exception class is
mapped from the name attribute of the xsd:complexType for the single message part.
This naming scheme enables the WSDL to Java mapping to map an xsd:complexType
derivation hierarchy to the corresponding Java exception class hierarchy. The following
section illustrates an example. Refer to the section

>From 6.5:
A SOAP fault is mapped to either a javax.xml.rpc.soap.SOAPFaultException, a
service specific exception class or RemoteException.

- Without this bug I could change of webservices runtime compliant with JAX-RPC and keep the
same Java code.
- AxisFault is not a service specific Exception and so should not derived from RemoteException.

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message