Re: Problem with exceptions and inherited fields (from Throwable)

[iksrazal <ik...@gmail.com>]

The way I handle exceptions decidely doesn't attempt to get involved with Axis 
Faults and mapping java exceptions to wsdl. Here's what I do - simple but has 
proven to work for me: 

<complexType name="ReturnWebBase">
        <sequence>
          <element name="errorMessage" type="string"/>
          <element name="successErrorCode"
type="int"/></sequence></complexType>

 <element name="webLoginResponse">
        <complexType>
          <complexContent>
            <extension base="tns:ReturnWebBase">
              <sequence>
                <element ref="tns:soap_session_id"/>
                <element ref="tns:web_user_name"/>
              </sequence>
            </extension>
          </complexContent>
        </complexType>
      </element>
 <element name="ReturnWebBaseResponse" type="ns2:ReturnWebBase"/>

Then all your return values get set like: 

<message name="WiseSWAEndpoint_webLogin">
     <part name="parameters" element="ns2:webLogin"/>
  </message>
  <message name="WiseSWAEndpoint_webLoginResponse">
    <part name="result" element="ns2:webLoginResponse"/>
  </message>

Or: 

<message name="WiseSWAEndpoint_despacharAutomatico">
    <part name="parameters" element="ns2:despacharAutomatico"/>
  </message>
  <message name="WiseSWAEndpoint_despacharAutomaticoResponse">
    <part name="result" element="ns2:ReturnWebBaseResponse"/>
  </message>

The point being just catch the exception: 

catch (Exception ex) {
            retElement.setErrorMessage(ex.getMessage());
            retElement.setSuccessErrorCode(-1);
}

That works for me 99% of the time. Different strokes for different folks. 

HTH,
iksrazal

Em Segunda 12 Dezembro 2005 14:21, o frantz escreveu:
> Hello,
>
> I am new with Axis and I think is a very good framework but the
> documentation isn't very verbose.
> I have a question : how to stop inheritance search in bean serialization
> (do not serialize ancestor's public fields) ?
>
> Is there an sample of this feature somewhere ?
> I have found a solution but I'm not completely satisfied with it.
>
> I am writing a Web Service connector for an existing Java application
> with the literal/wrapped mode.
> My connector exception extends the java.rmi.RemoteException one
> (according to the user's help advice) and I had registered a bean
> mapping for it.
> It works well but Axis always includes the "cause" field inherited from
> java.lang.Throwable in the SOAP message (I suppose it does this due to
> the getCause and initCause methods of this class).
>
> I don't want this field to be in the message because my connector must
> be interoperable and the "cause" field may have no equivalent in non
> Java frameworks.
> I haven't found in the documentation how to indicate to Axis that it
> should not serialize this field.
>
> When I use the java2wsdl tool, it always produces the following warning
> message :
> "- Please register a typemapping/beanmapping for
> 'services.myPackage.MyFault' " (I tried to define mapping set but it
> produced no change)
>
> I do this in the .wsdd deploying file :
>     <beanMapping xmlns:ns1="http://myPackage.services" qname="ns1:MyFault"
>             languageSpecificType="java:services.myPackage.MyFault" />
>
> but when I call the Axis online wsdl generator I can read the following
> warning message in the tomcat console :
> "- The class java.lang.Throwable is defined in a java or javax package
> and cannot be converted into an xml schema type.  An xml schema anyType
> will be used to define this class in the wsdl file."
>
> I also tried the --stopClasses java2wdsl option without success.
>
> Finally, I have investigated a bit further in the Axis source code (to
> understand how it really works) and I found 2 way of doing this.
> 1 - To edit by hand the wsdl file and remove the following lines :
>     <import namespace="http://lang.java">
>     ...
>     <element name="cause" nillable="true" type="xsd:anyType"/>
> and then generate (from this cleaned wsdl) server-side stubs and use
> them in the server code.
> 2 - To include metadata pieces of code in Exception classes to precise
> the serialization of the cause field.
> Secify it as an attribute (and it will not be serialized) or specify it
> as optional ( minOccurs="true") and ensure it will be always null by
> overriding the "getCause" method.
>
> Example :
> public class MyFault extends RemoteException implements Serializable
> {
>    ...
>
>     /**
>      * Overriden for smart serialization : use the retrieveCause()
> method instead.
>      * @return always null
>      * @see #retrieveCause()
>      */
>     public Throwable getCause()  {
>         return null; // do not serialize the value of this field
> (inherited from java.lang.Throwable)
>     }
>
>     /**
>      * Implements the original getCause beahvior.
>      * @see #getCause
>      */
>     public Throwable retrieveCause()  {
>         return super.getCause();
>     }
>
>     //-- Type metadata for Axis
>     private static org.apache.axis.description.TypeDesc typeDesc =  new
> org.apache.axis.description.TypeDesc(MyFault.class, false);
>
>     static  {
>         typeDesc.setXmlType(new
> javax.xml.namespace.QName("http://myPackage.services", "MyFault"));
>         org.apache.axis.description.ElementDesc elemField = new
> org.apache.axis.description.ElementDesc();
>         elemField.setFieldName("cause");
>         elemField.setXmlName(new
> javax.xml.namespace.QName("http://myPackage.services", "cause"));
>         elemField.setXmlType(new
> javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema", "anyType"));
>         elemField.setMinOccurs(0); // if null do not serialize this field
>         elemField.setNillable(true);
>         typeDesc.addFieldDesc(elemField);
>     }
>
>     /**
>      * Return type metadata object
>      */
>     public static org.apache.axis.description.TypeDesc getTypeDesc()  {
>         return typeDesc;
>     }
>
> }//-- End of class : MyFault ------
>
> I have rejected the 1st solution because I dont want (for many reasons)
> to include hundred lines of autogenerated code in my server.
> Currently, I am using the second solution, but I think it is a bit triky.
>
> Is there a better way to do this ?
>
> --
> Frantz <fr...@e-manation.com>