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