users@jax-rpc.java.net

Re: Internal wscompile error from custom WSDL

From: Ryan LeCompte <Ryan.LeCompte_at_pangonetworks.com>
Date: Sun, 8 May 2005 12:35:09 -0400

Anne,

 

Yes, that was a typo. It should have been <sequence/>. I am now using wrappers for both request and response messages. However, for arrays I am just using the "unwrapped array convention" for both request and response messages like you've indicated. Use of the unwrapped array convention does not hurt interoperability, correct? I know that you've shown me both ways to define arrays (wrapped vs. unwrapped) -- but I'm not exactly which approach you suggest I use to achieve the most interoperability possible.

 

Thanks,

Ryan

 

 

-----Original Message-----
From: Anne Thomas Manes [mailto:atmanes_at_gmail.com]
Sent: Sunday, May 08, 2005 11:10 AM
To: users_at_jax-rpc.dev.java.net
Subject: Re: Internal wscompile error from custom WSDL

 

Answers inline...

 

On 5/8/05, Ryan LeCompte <Ryan.LeCompte_at_pangonetworks.com> wrote:

>

>

> 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?

 

Don't know. Maybe someone from Sun can answer.

 

>

> 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>

 

Yes -- except that it should be <sequence/> rather than </sequence>.

 

>

> -- 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?

 

I recommend that you use the wrappers for both request and response

messages (that's the way .NET does it).

 

>

> Thanks,

>

> Ryan

>

> -----Original Message-----

>

> From: Anne Thomas Manes [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]

>

> > 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

>

> >

>

> >

>

> ---------------------------------------------------------------------

>

> 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