Mailing-List: contact axis-user-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-user@ws.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Message-Id: <200410272225.i9RMPcoP016048@host.concepthost.net>
From: "Anne Thomas Manes" <anne@manes.net>
To: <axis-user@ws.apache.org>
Subject: RE: WSDL2Java does not generate custom exception
Date: Wed, 27 Oct 2004 18:25:33 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <1098882747.417f9ebbda2dc@webmail.spansurf.com>
Thread-Index: AcS8KDshcJC/9O+mT7SZwD+41slWKQASlPpg

Steve, 

I'm working on the assumption that most users on this list don't read the
specs. (You shouldn't need to.) I've been involved with the development of
the specs, and I contribute my time to this list to try and help folks
understand the nuances of all this WS-Vertigo stuff. I didn't intend to
imply a recommendation to RTFM -- instead I dug out the references for you.


One of my goals in contributing to this list is to help ensure that Axis is
a true implementation of the specs. Therefore whenever I notice an
inconsistency with the specs, I cite it and request that someone file a bug
report. 

So I repeat, please file a bug report.

Thanks,
Anne 

-----Original Message-----
From: smcardle@spansurf.com [mailto:smcardle@spansurf.com] 
Sent: Wednesday, October 27, 2004 9:12 AM
To: axis-user@ws.apache.org
Subject: RE: WSDL2Java does not generate custom exception

Hi Anne,

I appreciate that the specs define one thing and Axis does another, rightly
or 
wrongly. However, most of the questions on this mailing list are to do with 
Axis as implemented. 

My point was that as Axis 1.1 is implement it may not meet the spec but to 
achieve the goal outlined by the original poster the WSDL snippets I posted 
were real world examples showing that his problem was fixable with Axis even
if 
the spec states otherwise.

Many people who post here like examples to show solutions to their problems
and 
quoting the specs does not help them out as they are generally less familiar

with SOAP services in general and Axis in particular. The old "RTFM"
approach 
often only serves to give these people the opinion that nobody is realy 
interested in their problem and causes them more frustration.

But you are quite correct, Axis does not always follow the specs and neither
do 
other Web Service tool kits like GLUE. However, These are the tools we
choose 
to do our job and these are the tools that cause us problems. So, if I have
a 
problem I often consult the spec (often very hard to understand, especially
for 
a new comer) and if it does not work with my toolset I try to experiment and

debug or ask advice on this mailing list to see if somebody else has solved 
this or a similar issue.

Regards

Steve

Quoting Anne Thomas Manes <anne@manes.net>:

> Steve, 
> 
> I'm quoting the specs. Per the specs, faults must be defined as
> document/literal. That fact that it works when defined as rpc/encoded just
> means that Axis (and Glue) are lax in their support of the specs. 
> 
> If Axis generated this WSDL file, then it's a bug. If it processed this
WSDL
> file without raising a warning, it's a bug. It is not compliant with the
> specifications.
> 
> Please file a bug report.
> 
> Anne
> 
> 
> -----Original Message-----
> From: smcardle@spansurf.com [mailto:smcardle@spansurf.com] 
> Sent: Wednesday, October 27, 2004 4:21 AM
> To: axis-user@ws.apache.org
> Subject: RE: WSDL2Java does not generate custom exception
> 
> 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 <anne@manes.net>:
> 
> > 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: smcardle@spansurf.com [mailto:smcardle@spansurf.com] 
> > Sent: Monday, October 25, 2004 11:21 AM
> > To: axis-user@ws.apache.org
> > 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 <moraleslos@hotmail.com>:
> > 
> > > 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
> > > 
> > > 
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
>