AXIS 1.4 ajoute des éléments à type de défaut personnalisé

Question

Peut-être quelqu'un a trouvé une solution pour le problème suivant:

Il semble que AXIS 1.4 ajoute un <exceptionName> et un élément <hostname> à chaque élément de défaut personnalisé. Dans le WSDL, le défaut est défini pour ne comporter qu'un message d'erreur personnalisé systemMessage.

Ceci est la réponse retournée par mon service. Peu importe l'erreur, il peut s'agir d'une erreur renvoyée en tant que faute.

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

Il semble que cela est un error dans l'axe 1.4. Est-ce que quelqu'un sait une solution de contournement pour ce comportement?

Answer 1

Il y a une solution pour le problème:

Dans la classe de défaut AXIS généré qui va de org.apache.axis.AxisFault modifier les constructeurs comme suit afin de supprimer les éléments (ci-dessous est la classe de défaut qui est utilisé pour l'erreur renvoyée dans la 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; 
} 

Cette solution de contournement résout le problème. Néanmoins, chaque fois que vous régénérez votre code pour le service Web SOAP, vous devez adapter la classe de panne.