Anne,
Thank you for the explanation. I have written my WSDL such that all array return types use the "unwrapped array convention", and all of the arguments to my operations use the wrapped convention. All of the service endpoint code that is now generated from the WSDL appears to look correct (i.e., no use of wrapped types where I would expect them to be their true types, like Item[] vs. Items). However, I should note that the only way that I could get the return types to use Item[] vs. Items was when I specified the -f:unwrap option to wscompile. If I didn't specify that option, then the generated code used the wrapped type instead of Item[]. Any ideas why that would be the case?
Also, a couple more questions if you don't mind:
-- I have been defining operations that have no parameters by still using the wrapped convention for multiple parameters, however the wrapped complexType just has an empty sequence. This appears to be working fine, but I just wanted to confirm that is the correct approach.
<complexType name="getItemsRequest">
</sequence>
</complexType>
-- Also, for operations that return a user-defined complex type, such as "Item" -- should the message "part" just directly refer to an element that is defined like:
<element name="getItemsResponse" type="tns:Item"/>
Or should it refer to an element that wraps an Item? I have been using the above way and the generated code correctly uses "Item" as the return type. In other words, is the wrapped convention necessary for return types, or just operation parameters?
Thanks,
Ryan
-----Original Message-----
From: Anne Thomas Manes [mailto:atmanes_at_gmail.com <mailto:atmanes_at_gmail.com> ]
Sent: Friday, May 06, 2005 8:18 PM
To: users_at_jax-rpc.dev.java.net
Subject: Re: Internal wscompile error from custom WSDL
Ryan,
You don't want to use the -f:unwrap option -- that will produce a document/literal unwrapped service. And I just realised that this must be a point of confusion for you. There is a difference between using unwrapped arrays versus using the doc/literal unwrapped convention.
As I said before, you should always use the document/literal unwrapped convention. It determines whether or not JAX-RPC automatically generates wrapper elements for your input and output messages.
Wrapped versus unwrapped arrays refer to whether or not you create an element to group a set of repeating elements. Let me explain the difference between wrapped versus unwrapped arrays.
This is an example of an element (<stuff>) that contains a single element (<thing>) plus a wrapped array of items:
<stuff>
<thing>thing</thing>
<items>
<item>some stuff</item>
<item>more stuff</item>
</items>
</stuff>
The <items> element provides a wrapper for the set of repeating <item> elements.
It's defined like so:
<element name="stuff">
<complexType>
<sequence>
<element name="thing" type="string"/>
<element name="items" type="tns:ArrayOfItems"/>
</sequence>
</complexType>
</element>
<complexType name="ArrayOfItems">
<sequence>
<element name="item" type="tns:Item" maxOccurs="unbounded"/>
</sequence>
</complexType>
Notice that we created a type called "tns:ArrayOfItems" for the <items> wrapper element. In this case, <items> returns an object of type ArrayOfItems rather than Item[].
On the other hand, this is an example of an unwrapped array within the <stuff> element:
<stuff>
<thing>thing</thing>
<item>some stuff</item>
<item>more stuff</item>
</stuff>
Notice that there is no wrapper element around the set of items.
It's defined like so:
<element name="stuff">
<complexType>
<sequence>
<element name="thing" type="string"/>
<element name="item" type="tns:Item" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
In this case the <item> elements map to Item[].
Hope this helps,
Anne
On 5/6/05, Ryan LeCompte <ryan.lecompte_at_pangonetworks.com> wrote:
> Anne,
>
> I'm following your example of how to return arrays from operations as
> opposed to a wrapped data type, however when I run the wscompile
> utility my web service endpoint interfaces are still using the wrapped
> data type and not the regular array type. I'll try to investigate this
> further... I'm wondering if it has something to do with the way I'm
> invoking wscompile, but I'm specifiying the -f:wsi and -f:unwrap options.
>
> Also, do you have any recommendations for how to define operations
> using doc/literal that don't accept any parameters? I want to define
> an operation that has a return type but no arguments. Should I define
> a message that has no "part" elements, or should I define a complex
> type that has an empty "sequence"?
>
> Thanks,
> Ryan
>
> -----Original Message-----
> From: Anne Thomas Manes [mailto:atmanes_at_gmail.com <mailto:atmanes_at_gmail.com> ]
> Sent: Thursday, May 05, 2005 8:46 PM
> To: users_at_jax-rpc.dev.java.net
> Subject: Re: Internal wscompile error from custom WSDL
>
> Ryan,
>
> I recommend that you always use the wrapped convention. I also
> recommend that you not use nillable="true", because that causes
> interop problems. It's better to say minOccurs="0".
>
> If you want your service to accept or return Item[] rather than Items,
> then you must define the input element as a bare array rather than as
> a wrapped array (i.e., don't create an Items type or an arrayOfItems
> element). So for example, if you want the input message to accept
> Item[], define it this way (this is identical to the way I told you to
> describe the output message):
>
> <element name="handleItems">
> <complexType>
> <sequence>
> <element name="item" type="tns:Item"
> minOccurs="1" maxOccurs="unbounded"/>
> </sequence>
> </complexType>
> </element>
>
> For more information about arrays, I suggest you visit this site:
> http://wiki.apache.org/ws/DotNetInteropArrays <http://wiki.apache.org/ws/DotNetInteropArrays>
> (it's about Axis, but it applies to any JAX-RPC implementation)
>
> Anne
>
> On 5/5/05, Ryan LeCompte <ryan.lecompte_at_pangonetworks.com> wrote:
> > Anne,
> >
> > I was able to follow your suggestion about the return type and I now
> > see
> the
> > return type of the handleItems method to be Item[] instead of the "Items"
> > object. I basically added on to Doug's modified Test wsdl where he
> > wanted
> to
> > show me how I could achieve multiple parameters with doc/literal.
> > The current Test.wsdl (which is attached) generates the handleItems
> > method
> with
> > two arguments. However, the first argument is generated as type "Items"
> > where ideally it should be "Item[]", just like the return type. Any
> > ideas why it wouldn't be Item[]?
> >
> > Also, a more general question.... should I follow the doc/literal
> "wrapped"
> > convention even if I'm not writing an operation with "multiple arguments"?
> I
> > did this in a previous WSDL even though it was only taking a single
> > array type argument, and it has worked out fine.
> >
> > Thanks!
> >
> > Ryan
> >
> > -----Original Message-----
> > From: Anne Thomas Manes [mailto:atmanes_at_gmail.com <mailto:atmanes_at_gmail.com> ]
> > Sent: Wednesday, May 04, 2005 4:47 PM
> > To: users_at_jax-rpc.dev.java.net
> > Subject: Re: Internal wscompile error from custom WSDL
> >
> > If you want to build a document/literal service that exposes an
> > interface that takes multiple parameters, then you should use the
> > "wrapped" convention. See my blog entry for more info:
> >
> http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html <http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html> .
> > The "wrapped" convention is also described in Section 6.4.1 in the
> > JAX-RPC 1.1 spec. The wrapped convention makes document/literal look
> > and feel like rpc/literal, but it's more interoperable (especially
> > with .NET).
> >
> > To return an array of items, try defining the output message like so
> > (using a bare array rather than a wrapped array):
> >
> > <wsdl:message name="handleItemsResponse">
> > <wsd:part name=parameters element="xsdns:handleItemsReturn/>
> > <wsdl:message>
> >
> > And define the response element like so:
> >
> > <xsd:element name="handleItemsReturn">
> > <xsd:complexType>
> > <xsd:sequence>
> > <xsd:element name="item" type="xsdns:Item" nillable="false"
> > minOccurs="1" maxOccurs="unbounded"/>
> > </xsd:sequence>
> > </xsd:complexType>
> > </xsd:element>
> >
> > Anne
> >
> > On 5/4/05, Ryan LeCompte <ryan.lecompte_at_pangonetworks.com> wrote:
> > >
> > >
> > >
> > > I realize that for doc/literal web services you can only have one "part"
> > for
> > > each message to be WSI compliant. However, in the Test.wsdl file
> > > that's included in this message.. If you make the getItems
> > > operation return an array of items by adding an "output" element to the "handleItems"
> > operation,
> > > it always seems to generate an endpoint interface with "Items" as
> > > the
> > return
> > > type instead of "Item[]". Has anyone come across this before? It
> > > makes
> the
> > > argument Items[] correctly, but not for the return type.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Ryan
> > >
> > >
> > >
> > > ________________________________
> > >
> > >
> > > From: Ryan LeCompte [mailto:ryan.lecompte_at_pangonetworks.com <mailto:ryan.lecompte_at_pangonetworks.com> ]
> > > Sent: Wednesday, May 04, 2005 2:04 PM
> > > To: JAX-RPC
> > > Subject: Internal wscompile error from custom WSDL
> > >
> > >
> > >
> > > Hello all,
> > >
> > >
> > >
> > > I'm running across various issues with the "wscompile" utility in
> > > JWSDP
> > 1.5.
> > > The problem mainly arises when I have a "message" element in my
> > > custom
> > WSDL
> > > that has more than one "part" inner elements (basically I want a
> generated
> > > method with multiple parameters). I've written a simple test WSDL
> > > file
> > that
> > > can be used to illustrate the problem. Note that this is a
> > document/literal
> > > web service that I'm passing as input to wscompile so that the
> > corresponding
> > > Java objects can be generated. The wscompile command that I'm using is:
> > >
> > >
> > >
> > > wscompile -gen:server -model model -f:wsi -f:unwrap
> > > -f:documentliteral
> > -keep
> > > -s generated -d output/server -verbose -classpath . config.xml
> > >
> > >
> > >
> > > Note that I want the generated methods to use Item[] for method
> arguments
> > > and not the generated "Items" object. The following WSDL file
> illustrates
> > > the problem. If you take out the "param_two" from the message
> > > "TestWebService_handleItems" then wscompile generates the proper
> > artifacts.
> > > However, if you add an extra parameter ("part_two") as the WSDL is
> > currently
> > > written, then wscompile outputs the following error:
> > >
> > >
> > >
> > >
> > > [CustomClassGenerator: generating JavaClass for: Item]
> > >
> > > [CustomClassGenerator: generating JavaClass for: Items]
> > >
> > > [LiteralObjectSerializerGenerator: writing serializer/deserializer
> > > for: Item]
> > >
> > > [LiteralObjectSerializerGenerator: writing serializer/deserializer
> > > for: Items]
> > >
> > > error: generator error: internal error (should not happen):
> > > tie.generator.002
> > >
> > >
> > >
> > > Note that it still appears to generate all of the proper Java
> > > artifacts, except now the main endpoint interface that it
> > > generates uses the
> "Items"
> > > object as a parameter instead of "Item[]". Is there something
> > > wrong in
> the
> > > way that I'm writing the WSDL? I've also noticed that if I don't
> > > use the name of the operation as the element name for the "Items"
> > > complex type,
> > then
> > > the generated endpoint interface uses "Items" and not "Item[]".
> > >
> > >
> > >
> > > Can anyone point me in the right direction here?
> > >
> > >
> > >
> > > Thank you,
> > >
> > > Ryan
> > >
> > >
> > >
> > > Test.wsdl:
> > >
> > >
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > >
> > > <!-
> > >
> > > File: Test.wsdl
> > >
> > > -->
> > >
> > >
> > >
> > > <definitions name="TestWebService"
> > >
> > > targetNamespace="urn:com.test.webservice/1.0.0/wsdl"
> > >
> > > xmlns:tns="urn:com.test.webservice/1.0.0/wsdl"
> > >
> > > xmlns:xsdns="urn:com.test.webservice/1.0.0/types"
> > >
> > > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
> > >
> > > xmlns="http://schemas.xmlsoap.org/wsdl/">
> > >
> > > <!-- Types: Provides data type definitions used to
> > > describe
> > the
> > > messages exchanged. -->
> > >
> > > <types>
> > >
> > > <schema
> > > targetNamespace="urn:com.test.webservice/1.0.0/types"
> > >
> > >
> xmlns:tns="urn:com.test.webservice/1.0.0/types"
> >
> > >
> > >
> > > xmlns="http://www.w3.org/2001/XMLSchema">
> > >
> > > <complexType name="Items">
> > >
> > > <sequence>
> > >
> > >
> > > <element name="arrayOfItems" type="tns:Item" nillable="false"
> > >
> > >
> > > minOccurs="1" maxOccurs="unbounded">
> > >
> > >
> > > </element>
> > >
> > > </sequence>
> > >
> > > </complexType>
> > >
> > > <complexType name="Item">
> > >
> > > <sequence>
> > >
> > >
> > > <element name="itemIdentifier" type="string" nillable="false"/>
> > >
> > >
> > > <element name="itemName" type="string" nillable="true"/>
> > >
> > > </sequence>
> > >
> > > </complexType>
> > >
> > > <element name="handleItems"
> > > type="tns:Items" />
> > >
> > > <element name="itemElement"
> > > type="tns:Item"/>
> > >
> > >
> > > </schema>
> > >
> > > </types>
> > >
> > >
> > >
> > > <!-- Message: An abstract definition of the data being
> > > transmitted. -->
> > >
> > > <message name="TestWebService_handleItems">
> > >
> > > <part name="param_one"
> > element="xsdns:handleItems"/>
> > >
> > > <part name="param_two"
> > element="xsdns:itemElement"/>
> > >
> > > </message>
> > >
> > >
> > >
> > > <!-- PortType: An abstract definition of the
> > > operations. -->
> > >
> > > <portType name="TestWebServicePortType">
> > >
> > > <operation name="handleItems">
> > >
> > > <input
> > > message="tns:TestWebService_handleItems"/>
> > >
> > > </operation>
> > >
> > > </portType>
> > >
> > >
> > >
> > > <!-- Binding: The concrete protocol and data format
> > > for the operations and messages. -->
> > >
> > > <binding name="TestWebServiceBinding"
> > > type="tns:TestWebServicePortType">
> > >
> > > <soap:binding
> > > transport="http://schemas.xmlsoap.org/soap/http"
> > > style="document"/>
> > >
> > > <operation name="handleItems">
> > >
> > > <soap:operation
> > > soapAction="TestWebService/handleItems"/>
> > >
> > > <input>
> > >
> > > <soap:body
> > > use="literal"/>
> > >
> > > </input>
> > >
> > > </operation>
> > >
> > > </binding>
> > >
> > >
> > >
> > > <service name="TestWebService">
> > >
> > > <port name="TestWebServicePort"
> > > binding="tns:TestWebServiceBinding">
> > >
> > > <soap:address
> > > location="REPLACE_WITH_ACTUAL_URL"/>
> > >
> > > </port>
> > >
> > > </service>
> > >
> > > </definitions>
> > >
> > >
> > >
> > > Config.xml:
> > >
> > >
> > >
> > > <?xml version="1.0" encoding="UTF-8" ?>
> > >
> > >
> > >
> > > <configuration
> > > xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
> > >
> > > <wsdl location="C:/test/Test.wsdl"
> > >
> > > packageName="com.test "/>
> > >
> > > </configuration>
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> > For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net