Home/ Questions/Q 84593
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T21:57:20+00:00

Maybe someone found a workaround for the following problem: It seems as if AXIS

  • 0

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'>    <soapenv:Body>       <soapenv:Fault>          <faultcode>soapenv:Server.generalException</faultcode>          <faultstring/>          <detail>             <ns1:systemMessage xmlns:ns1='http://my.domain/workflow/engine/wsdl/types'>                <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/'>com.domain.commons.ws.schema.SystemMessageType</ns2:exceptionName>             <ns3:hostname xmlns:ns4='http://xml.apache.org/axis/'>my.host.com</ns3:hostname>          </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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 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.

    • 0