AXIS 1.4 adds elements to custom fault type

Question

Maybe someone found a workaround for the following problem:

It seems as if AXIS 1.4 adds an <exceptionName> and a <hostname> element to each custom fault element. In the WSDL the fault is defined to only consist of a custom fault message systemMessage.

This is the answer returned from my service. Never mind about the error, it could be any error that is returned as a fault.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
   <soapenv:Body>
      <soapenv:Fault>
         <faultcode>soapenv:Server.generalException</faultcode>
         <faultstring/>
         <detail>
            <ns1:systemMessage xmlns:ns1="http://my.domain/workflow/engine/wsdl/types"&gt;
               <message>nullcvc-datatype-valid.1.2.1: '2008-12-02T00:00:00' is not a valid value for 'date'.cvc-type.3.1.3</message>
               <code>XML string is not valid</code>
               <parameter/>
            </ns1:systemMessage>
            <ns2:exceptionName xmlns:ns2="http://xml.apache.org/axis/"&gt;com.domain.commons.ws.schema.SystemMessageType&lt;/ns2:exceptionName&gt;
            <ns3:hostname xmlns:ns4="http://xml.apache.org/axis/"&gt;my.host.com&lt;/ns3:hostname&gt;
         </detail>
      </soapenv:Fault>
   </soapenv:Body>
</soapenv:Envelope>

It seems as if this is an error in Axis 1.4. Does anyone know a workaround for this behaviour?

Answer 1

There's a workaround for the problem:

In the AXIS generated fault class that extends from org.apache.axis.AxisFault alter the constructors as follows in order to suppress the elements (below is the fault class that is used for the fault returned in the question):

public SystemMessageType() {
    // Suppress the two elements
    this.removeHostname();
    this.removeFaultDetail(org.apache.axis.Constants.QNAME_FAULTDETAIL_EXCEPTIONNAME);
}

public SystemMessageType(
       java.lang.String message1,
       java.lang.String code,
       java.lang.String[] parameter) {
    // Call the default constructor
    this();
    this.message1 = message1;
    this.code = code;
    this.parameter = parameter;
}

This workaround solves the problem. Nevertheless, whenever you regenerate your code for the SOAP web service you have to adapt the fault class.