I would like to add to this thread that I had a similar problem with custome 
exceptions.

The java2wsdl utility unfortuantely creates the SAME QName for the <fault> 
elements in the WSDL for a particular operation. So if you have several custome 
Exceptions thrown by your method the map kept by the generated classes fails to 
deserialise any custom exception but the first.

These QNames are derived from the namespace attribute of the fault element 
withing the WSDL binding element. If you manually change each of these to be 
urn:{ExceptionName} before using wsdl2java the auto generated code will 
deserialise the correct Exceptions.

P.S. RemoteException does NOT have to be listed in the fault elements of the 
operations

Regards

Steve


Quoting [EMAIL PROTECTED]:

> By throwing following Exception:
> 
>   package de.eis.skoda.gwo.ws.state.validierung;
>   import java.rmi.RemoteException;
>   public class GWException extends RemoteException {
>     private String message = null;
>     private FehlerBean[] fehlerBeans = new FehlerBean[0];
> 
>     public GWException() { super(); }
> 
>     public GWException(String message) { this.message = message; }
> 
>     public String getMessage() { return message; }
> 
>     public void setMessage(String message) { this.message = message; }
> 
>     public FehlerBean[] getFehlerBeans() { return fehlerBeans; }
> 
>     public void setFehlerBeans(FehlerBean[] fehlerBeans) { this.fehlerBeans
> =
> fehlerBeans; }
>   }
> 
> 
>   package de.eis.skoda.gwo.ws.state.validierung;
>   import java.io.Serializable;
>   public class FehlerBean implements Serializable {
>     private String gerkz = null;
>     private Integer gercod = null;
>     private String gertxt = null;
> 
>     public FehlerBean() {
>     }
> 
>     public FehlerBean(String gerkz, Integer gercod, String gertxt) {
>       this.gerkz = gerkz;
>       this.gercod = gercod;
>       this.gertxt = gertxt;
>     }
> 
>     public String getGerkz() { return gerkz; }
> 
>     public void setGerkz(String gerkz) { this.gerkz = gerkz; }
> 
>     public Integer getGercod() { return gercod; }
> 
>     public void setGercod(Integer gercod) { this.gercod = gercod; }
> 
>     public String getGertxt() { return gertxt; }
> 
>     public void setGertxt(String gertxt) { this.gertxt = gertxt; }
>   }
> 
> 
> Client receives the following XML Stream:
> 
>   <?xml version="1.0" encoding="UTF-8"?>
>   <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.userException</faultcode>
>         <faultstring>de.eis.test.ws.state.validierung.GWException: Die
> Antragsdaten sind fehlerhaft</faultstring>
>         <detail>
>           <de.eis.test.ws.state.validierung.GWException
> xsi:type="ns1:GWException"
> xmlns:ns1="http://validierung.state.ws.test.eis.de";>
>             <fehlerBeans xsi:type="soapenc:Array"
> soapenc:arrayType="ns1:FehlerBean[1]"
> xmlns:ns2="http://action.ws.test.eis.de";
> xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/";>
>               <item>
>                 <gerkz xsi:type="xsd:string">661</gerkz>
>                 <gercod xsi:type="xsd:int">661</gercod>
>                 <gertxt xsi:type="xsd:string">Kilometerstand muss 1 bis 4
> stellige Zahl sein</gertxt>
>               </item>
>             </fehlerBeans>
>             <message xsi:type="xsd:string">Die Antragsdaten sind
> fehlerhaft</message>
>           </de.eis.skoda.gwo.ws.state.validierung.GWException>
>         </detail>
>       </soapenv:Fault>
>     </soapenv:Body>
>   </soapenv:Envelope>
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Tom Jordahl [mailto:[EMAIL PROTECTED] 
> Gesendet: Freitag, 2. April 2004 00:10
> An: '[EMAIL PROTECTED]'
> Betreff: RE: Exception Handling - possible solution
> 
> 
> 
> You are enhancing the Axis specific Hack that send the class name of the
> exception over the wire.  I invented this (and it was bad) a long time ago.
> 
> 
> Axis now uses the <details> element in the fault to locate the correct
> Exception class.  A table of QNames to Exception class names is kept and
> each
> child element of <details> is looked up in this table until we find a match
> (or don't, then we throw an AxisFault).
> 
> This functions correctly, see java/test/wsdl/faults for some test cases that
> work.
>  
> --
> Tom Jordahl
> Macromedia Server Development
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, April 01, 2004 3:24 PM
> To: [EMAIL PROTECTED]
> Subject: AW: Exception Handling - possible solution
> 
> Hello,
> 
> I looked through the sourcecode of Axis 1.1. By a few small changes can xml
> stream deserialized correctly. In the attachment of this email lie 3
> classes,
> which I changed. The changes, which I made are commented und can be found by
> searching for "007". Can someone look through the changes and say whether it
> ok is or perhaps You be able to use the changes in the next Version.
> 
> Excuse me for my englich.
> 
> Many Thanks,
> Alexander Becker
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Steve Loughran [mailto:[EMAIL PROTECTED] 
> Gesendet: Dienstag, 23. März 2004 11:08
> An: [EMAIL PROTECTED]
> Betreff: Re: Exception Handling
> 
> 
> [EMAIL PROTECTED] wrote:
> > Hello,
> > 
> > I have "de.eis.ws.axis.WSException extends RemoteException" class on
> > server side. Via Java2WSDL & WSDL2Java was generated 
> > "de.eis.ws.axis.WSException extends AxisFault" for a client side.
> > When the Exception is triggered on the server side, a client receives the
> > following XML stream:
> > 
> >   <?xml version="1.0" encoding="UTF-8"?>
> >   <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.userException</faultcode>
> >      <faultstring>de.eis.ws.axis.WSException</faultstring>
> >      <detail>
> >       <de.eis.ws.axis.WSException xsi:type="ns1:WSException"
> > xmlns:ns1="http://axis.ws.eis.de";>
> >        <message xsi:type="xsd:string" xsi:nil="true"/>
> >       </de.eis.ws.axis.WSException>
> >      </detail>
> >     </soapenv:Fault>
> >    </soapenv:Body>
> >   </soapenv:Envelope>
> > 
> > Axis deserialize this Stream to an AxisFault.
> > Is there a way to deserialize this Stream to
> > "de.eis.ws.axis.WSException extends AxisFault" class, which was 
> > generated via WSDL2Java?
> 
> In theory, Axis should follow the exception marshalling behaviour of 
> JAX-RPC. If this is not happening, then we have a bug.
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: James Turner [mailto:[EMAIL PROTECTED] 
> Gesendet: Dienstag, 18. Mai 2004 02:59
> An: [EMAIL PROTECTED]
> Betreff: How to craft a custom Fault detail message?
> 
> 
> Hi there,
>    I'm trying to create custom detail messages to indicate the nature of
> request faults, so that they can appropriately be handled on the client
> side.
> I've been told by Those Who Know that I shouldn't use anything beyond Client
> or Server in the faultcode to be compatible with the Basic Profile, so I
> need
> to pass details in.. well, the details.
>  
>    Everything is fine, except that I was also told to use a custom namespace
> for the tags in the detail, to avoid collisions.  Fair enough, and here's my
> utility method to create the AxisFault:
>  
>     static final String NS = "http://benefit-systems.com/faults/exceptions";;
>     static final String XMLNS_NS = "http://www.w3.org/2000/xmlns/";;
>     private AxisFault generateAxisFault(String type, String desc, String
> errorName, String errorDetail) {
>         String where = "http://secure.benefit-systems.com";;
>             DocumentBuilderFactory dbf =
> DocumentBuilderFactory.newInstance();
>         DocumentBuilder db = null;
>         try {
>             db = dbf.newDocumentBuilder();
>         } catch (ParserConfigurationException e) {
>             e.printStackTrace(); 
>         }
>         Document doc = db.newDocument();
>         Element error = doc.createElementNS(NS, "e:error");
>         doc.appendChild(error);
>         error.setAttributeNS(XMLNS_NS, "xmlns:e", NS);
>         Element errorcode = doc.createElementNS(NS, "e:errorcode");
>         error.appendChild(errorcode);
>         errorcode.appendChild(doc.createTextNode(errorName));
>         Element errordetail = doc.createElementNS(NS, "e:errordetail");
>         error.appendChild(errordetail);
>         errordetail.appendChild(doc.createTextNode(errorDetail));
>         Element[] detail = {error};
>         AxisFault fault = new AxisFault(type, desc, where, detail);
>         return fault;
>     }
> 
> Unfortunately, in spite of all the messing around with namespaces, what
> comes
> out is:
> 
> <soapenv:Envelope>
>   <soapenv:Body>
>     <soapenv:Fault>
>       <faultcode>ns1:Client</faultcode>
>       <faultstring>Bad Username or Password</faultstring>
>       <faultactor>http://secure.benefit-systems.com</faultactor>
>       <detail>
>         <e:error>
>           <e:errorcode>Authentication</e:errorcode>
>           <e:errordetail/>
>         </e:error>
>       </detail>
>      </soapenv:Fault>
>    </soapenv:Body>
> </soapenv:Envelope>
> 
> One will notice the conspicuous lack of an xmlns field.  Searching on the
> web, it seems like everybody has the same problem with Xerces in general.
> Any
> ideas?  I suppose I could generate the wrapping error tag using non-XML
> methods to force the xmlns line, but that's gross.
> 
> 




Reply via email to