Hi Anne This is not true. The excepts I included in the previous post are direct extracts from my WSDL. All I did was remove all the other exceptions thrown from my operation and left just the one for brevity.
This particular SOAP service has aprox 80 operations and all but a few throw custom exceptions. The service is Axis 1.1 and our clients are GLUE. The only problem I encountered with the custome exceptions is that WSDL2Java gives them all the same QName and therefor when looked up in the map for deserialisation only the first exception type would be found. To get over this just edit the WSDL before generating the java code to change the QNames to be unique within an operation. All then works fine. If you already have an impl class generated from an earlier run you will need to either rename it or remove it. Regards Steve Quoting Anne Thomas Manes <[EMAIL PROTECTED]>: > Note, though, that fault messages MUST be defined as document/literal rather > than rpc/encoded, per the WSDL 1.1 specification [1]: > > <wsdlExcerpt> > 3.6 soap:fault > The soap:fault element specifies the contents of the contents of the SOAP > Fault Details element. It is patterned after the soap:body element (see > section 3.5). > > <definitions .... > > <binding .... > > <operation .... > > <fault>* > <soap:fault name="nmtoken" use="literal|encoded" > encodingStyle="uri-list"? namespace="uri"?> > </fault> > </operation> > </binding> > </definitions> > > The name attribute relates the soap:fault to the wsdl:fault defined for the > operation. > > The fault message MUST have a single part. The use, encodingStyle and > namespace attributes are all used in the same way as with soap:body (see > section 3.5), only style="document" is assumed since faults do not contain > parameters. > </wsdlexcerpt> > > Also see WS-I Basic Profile [2]: > > <wsiExcerpt> > 4.4.2 Bindings and Faults > There are several interpretations for how wsdl:part elements that describe > soapbind:fault, soapbind:header, and soapbind:headerfault may be defined. > > R2205 A wsdl:binding in a DESCRIPTION MUST refer, in each of its > soapbind:header, soapbind:headerfault and soapbind:fault elements, only to > wsdl:part element(s) that have been defined using the element attribute. > > Because faults and headers do not contain parameters, soapbind:fault, > soapbind:header and soapbind:headerfault assume, per WSDL 1.1, that the > value of the style attribute is "document". R2204 requires that all > wsdl:part elements with a style attribute whose value is "document" that are > bound to soapbind:body be defined using the element attribute. This > requirement does the same for soapbind:fault, soapbind:header and > soapbind:headerfault elements. > </wsiExcerpt> > > [1] http://www.w3.org/TR/wsdl#_soap:fault > [2] > http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html#Bindings_and_F > aults > > - Anne > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Monday, October 25, 2004 11:21 AM > To: [EMAIL PROTECTED] > Subject: Re: WSDL2Java does not generate custom exception > > OK > > First define your exception as a complex type as follows: > > <complexType name="SystemFailureException"> > <sequence> > <element name="sourceException" nillable="true" > type="xsd:anyType"/> > </sequence> > </complexType> > > Next define the message as follows: > > <message name="SystemFailureException"> > <part name="fault" type="ex1:SystemFailureException"/> > </message> > > N.B. The part name attribute is "fault" > > Next define the operation in the portType section of your WSDL as follows: > > <operation name="getChargeForProductMigrationOrder"> > <input message="tns:getChargeForProductMigrationOrderRequest"/> > <output message="tns:getChargeForProductMigrationOrderResponse"/> > <fault message="tns:SystemFailureException" > name="SystemFailureException"/> > </operation> > > > Lastly in the binding section define the operation as follows: > > <operation name="getChargeForProductMigrationOrder"> > <soap:operation soapAction="urn:getChargeForProductMigrationOrder"/> > <input> > <soap:body > encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; > namespace="urn:ESelfcareSoap" use="encoded"/> > </input> > <output> > <soap:body > encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; > namespace="urn:ESelfcareSoap" use="encoded"/> > </output> > <fault name="SystemFailureException"> > <soap:fault > encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"; > namespace="urn:SystemFailureException" use="encoded"/> > </fault> > </operation> > > Pay attention to the name spaces' > > This will then generate the Impl class with the correct throws clauses and > these exceptions will be accessable directly within the client. These > exceptions do not have to implement the Axis Fault. > > Hope this helps > > Steve > > Quoting Los Morales <[EMAIL PROTECTED]>: > > > Hi, > > > > I have a question on how Axis 1.1 generates a user-defined fault through > the > > > > WSDL2Java tool. I have defined a schema for an exception I want to return > > > whenever something wrong happens during Web Service processing. In my > > custom WSDL, I specified this exception in the message, portType and > binding > > > > definitions. When I use the WSDL2Java tool to generate the server-side > > skeleton, I do not see this exception in any throws clause or defined > > anywhere except in the deploy.wsdd file. The Exception class gets > generated > > > > properly from the schema but does not look like Axis knows how to put this > > > into the service. I have attached portions of my code below. Any advice > > would be appreciated. Thanks! > > > > -los > > > > #### Schema #### > > .... > > <xsd:element name="ProcessingFault" type="ProcessingProblemType"/> > > > > <xsd:complexType name="ProcessingProblemType"> > > <xsd:sequence> > > <xsd:element name="exceptionMessage" type="xsd:string" > > minOccurs="0"/> > > </xsd:sequence> > > </xsd:complexType> > > .... > > ############## > > > > ### WSDL #### > > > > <!-- message definitions --> > > .... > > <message name="DownloadError"> > > <part name="error" element="fault:ProcessingFault"/> > > </message> > > > > <!-- port type definitions --> > > <portType name="DownloadPortType"> > > <operation name="downloadPrograms"> > > .... > > <fault name="ProcessingProblemMessage" > message="tns:DownloadError"/> > > </operation> > > </portType> > > > > > > <!-- binding definitions --> > > ... > > <fault name="ProcessingProblemMessage"> > > <soap:fault name="ProcessingProblemMessage" use="literal"/> > > </fault> > > > > ############ > > > > _________________________________________________________________ > > Get ready for school! Find articles, homework help and more in the Back to > > > School Guide! http://special.msn.com/network/04backtoschool.armx > > > > > > > > >
