Hi,
today I've got two problems concerning wsdl-interpretation during generation
of the Java(-Service-)Classes with the wsdl2JavaTask of apollo.
First Question:
If my wsdl-file contains message-elements with zero or more then one
part-elements, a runtime-exception is thrown by the class OperationInfo,
saying "Wsdl input element should have exactly one part.".
WSDL1.1 specifies the number of part-elements in a message-elements with "*"
meaning zero till unbounded.
If I encapsulate the part-elements in a new element and use this in the
message-declaration, everything works fine.
It seems the implementation differs in that point to the wsdl
1.1-specification. Is that so? Why is that so?
example:
<types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
targetNamespace="http://bookstore.com/ShoppingCart";
xmlns="http://www.w3.org/2001/XMLSchema";
xmlns:tns="http://bookstore.com/ShoppingCart";
xmlns:wsrl="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceLifetime-1.2-draft-01.xsd";
xmlns:wsbf="http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-BaseFaults-1.2-draft-01.xsd";
elementFormDefault="qualified">
<xs:element name="CustomerId" type="xs:string"/>
<xs:element name="CustomerIdCreateCart" type="xs:string"/>
<xs:element name="CustomerIdOrderCart" type="xs:string"/>
<xs:element name="ProductId" type="xs:string"/>
<xs:element name="Price" type="xs:int"/>
<xs:element name="Quantity" type="xs:int"/>
<xs:element name="ArticleOrder">
<xs:complexType>
<xs:sequence>
<xs:element ref="tns:ProductId"/>
<xs:element ref="tns:Quantity"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</types>
...
works fine
=========
<message name="AddArticleRequest">
<part name="ArticleOrder" element="tns:ArticleOrder"/>
</message>
doesn't work
=============
<message name="AddArticleRequest">
<part name="CustomerID" element="tns:CustomerId"/>
<part name="Quantity" element="tns:Quantity"/>
</message>
Second Question:
If a defined type-element is used in more then one messages for different
operations, only the last operation that uses the element in it's
message-type is generated into the CustomerOperationsPortType.
That means, i can't use defined type-elements more then one time and have to
define equivalent elements with an other, unique name.
Why is that so? WSDL 1.1 don't specify such an restriction.
example:
(assuming the same type definitions as in the example for the first
question)
doesn't work
=============
message-definitions:
<message name="CreateCartRequest">
<part name="CustomerId" element="tns:CustomerId"/>
</message>
<message name="CreateCartResponse">
<part name="Created" element="xs:boolean"/>
</message>
...
<message name="OrderCartRequest">
<part name="CustomerId" element="tns:CustomerId"/>
</message>
<message name="OrderCartResponse">
<part name="TotalPrice" element="tns:Price"/>
</message>
operations-definitions:
<operation name="CreateCart">
<input message="tns:CreateCartRequest"/>
<output message="tns:CreateCartResponse"/>
</operation>
...
<operation name="OrderCart">
<input message="tns:OrderCartRequest"/>
<output message="tns:OrderCartResponse"/>
</operation>
result:
only the createCart-Operation is provided in the generated
MyServiceCustomOperationsPortType.java, the orderCart-Operation is lost.
works fine
=============
message-definitions:
<message name="CreateCartRequest">
<part name="CustomerId" element="tns:CustomerIdCreateCart"/>
</message>
<message name="CreateCartResponse">
<part name="Created" element="xs:boolean"/>
</message>
...
<message name="OrderCartRequest">
<part name="CustomerId" element="tns:CustomerIdOrderCart"/>
</message>
<message name="OrderCartResponse">
<part name="TotalPrice" element="tns:Price"/>
</message>
operations-definitions:
<operation name="CreateCart">
<input message="tns:CreateCartRequest"/>
<output message="tns:CreateCartResponse"/>
</operation>
...
<operation name="OrderCart">
<input message="tns:OrderCartRequest"/>
<output message="tns:OrderCartResponse"/>
</operation>
result:
both operations are provided in the generated
MyServiceCustomOperationsPortType.java
Any ideas?
Thank You
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
