Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-user@ws.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-Id: <9DB9F739ED54ED4891E0787F4A78108DBC37C7@us-suffolk.mail.saic.com>
From: "McMullin, Gregg E." <GREGG.E.MCMULLIN@saic.com>
To: axis-user@ws.apache.org
Subject: RE: faults and wsdd
Date: Thu, 22 Dec 2005 12:45:19 -0500
MIME-Version: 1.0
Content-Type: text/plain
Sender: GREGG.E.MCMULLIN@saic.com

Thanks Frantz:

  I use --serverSide = true and --skeletonDeploy=true. I looked
at your solutions and need to stay away from putting any metadata
into the Fault class itself.  I don't see the typemapping/beanmapping
error that you see.  The beanMapping is generated for me based upon
my wsdl file.  What is not generated for me is the <operation> element.

 Not sure what you mean by serverSide stubs, but I use all of the
generated code from the wsdl2java tool, so I believe that I too use
serverSide stubs.  Maybe that my problem is within my custom Fault
class.  I'll have to recheck to ensure that it is serializable etc.

      thanks,

           Gregg


-----Original Message-----
From: axis-user-return-39534-GREGG.E.MCMULLIN=saic.com@ws.apache.org
[mailto:axis-user-return-39534-GREGG.E.MCMULLIN=saic.com@ws.apache.org] 
Sent: Thursday, December 22, 2005 12:27 PM
To: axis-user@ws.apache.org
Subject: Re: faults and wsdd

Hi Gregg,

I have had a similar problem.

I have use wsdl2Java with the following options
--serverSide = true
--skeletonDeploy = false
to generate operations tags and I have copied them in my original wsdd file.

You can also use server-side stubs. (with server-side stubs : no need of
opreations tags)

--
Frantz

PS : Also, you can see the following message that I have posted in this 
list last week which deals around this subjet.

-------------------------------
Subject : Problem with exceptions and inherited fields (from Throwable)
Date : 12-12-2005

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 ?

McMullin, Gregg E. wrote :

>Hi All:
>
>  Is there a way to make the wsdl2Java tool generate the operation tag 
>within the generated deploy.wsdd file?  I'm having trouble serializing
>defined faults.  The User documentation appears to say that I need to
>manually add the operation tag to the wsdd if I want faults to be
>serialized properly.  Is this true?  Why isn't it enough to defined
>in the wsdl?  Does someone have a simple, but complete example of the
>steps to get this working properly?  Thanks for any feedback!
>
>  Gregg
>