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]
> 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
> (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]
> > 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.
> > 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]
> > > 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
>
>