Hi Bill,
do u already try to map your array in your WSDD ? Something like that :
<typeMapping
xmlns:ns="urn:MyNS"
qname="ns:Employe"
type="java:bill.keese.Employe"
serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"
deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"
encodingStyle=""
/>
<typeMapping
xmlns:ns="urn:MyNS"
qname="ns:ArrayOfEmployee"
type="java:bill.keese.Employe[]"
serializer="org.apache.axis.encoding.ser.ArraySerializerFactory"
deserializer="org.apache.axis.encoding.ser.ArrayDeserializerFactory"
encodingStyle=""
/>
---------------
Sebastien
On Thu, 17 Feb 2005 15:15:17 +0900, Bill Keese
<[EMAIL PROTECTED]> wrote:
> Wow, great answer. Thanks! I was actually just asking about issue #2,
> wrapped or bare arrays.
>
> I looked over the Axis code again and realized that in ArraySerializer.java
> version 1.31, the code I mentioned in my previous mail was corrected to
> output wrapped or bare arrays in concordance with the WSDL file. The
> problem is that there is still a bug when an operation returns an array
> directly, rather than a structure containing an array (ie, an operation
> like "Employee[] getEmployees()").
>
> Bill
>
> Dino Chiesa wrote:
>
> I am not clear. Seems there are two issues,
> 1. SOAP encoding (blaaaach!) vs Literal
> 2. wrapped or bare arrays
>
> Let's stay away from SOAPENC:arrayType since we all listen to WS-I.
>
> So, on issue #2, are you asking, does .NET expect arrays embedded in types
> to be serialized as [Example 1]:
> <Container>
> <param1> foo</param1>
> <wrapper>
> <param2>bar</param2>
> <param2>blah</param2>
> ...
> </wrapper>
> </Container>
>
> or as [Example 2]
>
>
> <Container>
> <param1> foo</param1>
> <param2>bar</param2>
> <param2>blah</param2>
> ...
> </Container>
> ?
>
> The answer is, .NET can go either way. It takes its cue from the WSDL.
>
> If the WSDL uses a complexType to wrap an array, such as this:
>
>
>
>
> <s:complexType name="Container">
> <s:sequence>
> <s:element minOccurs="1" maxOccurs="1" name="param1" nillable="true"
> type="s:string" />
> <s:element minOccurs="1" maxOccurs="1" name="wrapper" nillable="true"
> type="tns:ArrayOfString" />
> </s:sequence>
> </s:complexType>
> <s:complexType name="ArrayOfString">
> <s:sequence>
> <s:element minOccurs="0" maxOccurs="unbounded" name="param2"
> type="s:string" />
> </s:sequence>
> </s:complexType>
>
> ... then .NET will expect the XML on the wire to be "wrapped", as in
> [Example 1] above. If the WSDL does not use a complexType to wrap the
> array, but instead uses an element with maxOccurs != 1, like so:
>
> <s:complexType name="Container">
> <s:sequence>
> <s:element minOccurs="1" maxOccurs="1" name="param1" nillable="true"
> type="s:string" />
> <s:element minOccurs="0" maxOccurs="unbounded" name="param2"
> type="s:string" />
> </s:sequence>
> </s:complexType>
>
> ...then .NET will expect XML on the wire that does not wrap the array in an
> element, such as in [Example 2] above.
>
> So you can do whatever.
>
>
> > what format do people usually use?
>
> I guess it's a matter of style and taste. From the app programmer's
> perspective, the generated type on the .NET side behaves the same. It looks
> like this:
>
> public class Container {
> public string param1;
> public string[] param2;
> }
>
> The metadata attached to the type (in the form of inline code attributes)
> tells the .NET XML serializer whether to use a wrapper element or not.
>
> So the differences in on-the-wire serialization don't bubble up to the .NET
> programmer. Personally I find the use of "ArrayOfX" to be clunky in the WSDL
> and XSD. But it reads more nicely in the serialized XML, and so I
> generally prefer it in complex schema. In simple schema, I don't care.
>
>
> -D
>
>
> ________________________________
> From: Bill Keese [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 16, 2005 9:18 PM
> Cc: [EMAIL PROTECTED]
> Subject: Re: rpc/literal vs document/literal, and returning a list of
> objects
>
> Dino - question for you. The checkin comment for ArraySerializer v1.5 is
> listed below. It implies that .NET *doesn't* want arrays serialized using
> the <item> tag. And yet, all the examples I've seen of .NET services
> indicate the opposite. Can you shed some light on this? And if your answer
> is ".NET clients support either case as long as the XML response obeys the
> WSDL file", then, what format do people usually use?
>
> ArraySerializer v1.5 checkin comment:
> Support serializing Arrays in "literal" fashion (a .NET-ism). We introduce
> an "isEncoded" flag on the MessageContext for now - this really wants to get
> set to the encoding state we're in at present, but I couldn't figure out how
> to coax that out of the serialization code yet. Let's say we have: class
> Bean { public String field1; public String [] field2; } if isEncoded is true
> (the default), we get XML that looks like: <bean> <field1>hi there</field1>
> <field2 SOAPENC:arrayType="xsd:string[2]"> <item>1</item> <item>2</item>
> </field2> </bean> whereas if isEncoded is false, we now get: <bean>
> <field1>hi there</field1> <field2>1</field2> <field2>2</field2> </bean>
> TODOs: 1) Figure out how to get encodingStyle for real 2) Implement
> deserializing from arrays encoded like this Bill
>
>
> Bill Keese wrote:
> Hi Dino,
>
> Nice to hear input from someone on the MS side. Anyway, yes, I think the
> array issue is specific to Axis v1.2, and it's documented in
> http://issues.apache.org/jira/browse/AXIS-1547
>
> The patch specified in the bug report seems to fix most people's array
> related problems. (It's not in CVS so you have to check out the Axis code
> and modify it yourself.)
>
> Bill
>
> Dino Chiesa wrote:
> Returning arrays from AXIS to .NET? Using AXIS v1.1 server, and .NET v1.1 -
> it works for me. Here's a working sample with code.
> http://dinoch.dyndns.org:7070/axis/AboutBasics.jsp I know this must be a
> repeat, but I looked in the archive and did not see it. . . Is the arrays
> issue specific to AXIS v1.2? -----Original Message----- From: Praveen Peddi
> [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 15, 2005 3:32 PM
> To: [EMAIL PROTECTED]; Anne Thomas Manes Subject: Re: rpc/literal vs
> document/literal, and returning a list of objects But what about the
> doc/literal issues related to returning array of beans. Wouldn't Dan hit the
> wall at some point. Atleast I hit the wall when I tried to move towards
> doc/literal. We were using rpc/encoded style before and everything was
> working great. When I read that rpc/encoded has permance problems I tried to
> move to doc/literal style (actually wrapped/literal) but I was stuck with
> returning arrays issue. My .NET client doesn't serialize the beans at all. I
> read the Eric's thread and other email threads related to this issue but
> could not really come up with a solution. Praveen ----- Original Message
> ----- From: "Anne Thomas Manes" <[EMAIL PROTECTED]> To:
> <[EMAIL PROTECTED]> Sent: Tuesday, February 15, 2005 12:47 PM Subject:
> Re: rpc/literal vs document/literal, and returning a list of objects
> And just to clarify... The difference between doc/literal and
> wrapped/literal is in the way you invoke the service -- the contents on the
> wire (the structure of the SOAP message) will be identical. In doc/literal,
> you input an object (javabean), and you return an object (javabean). In
> wrapped/literal, you input parameters, and you return an object.
> Wrapped/literal is a programming convention that make doc/literal look like
> rpc/literal. Don't use rpc/literal because .NET doesn't support it. Regards,
> Anne On Tue, 15 Feb 2005 16:55:36 +0000, Tom Oinn <[EMAIL PROTECTED]> wrote:
> Dan, My suggestion would be to use document / literal style. The data
> structure you describe is easy to define as an XML schema (by hand if
>
> you must, but I'd use something like XMLSpy). You can then create the
>
> requisite WSDL file referencing this schema, generate the server side
>
> Java classes against this and modify them to call the appropriate methods
> on your existing EJB. If you're using doc/literal style you'll also have to
> build a (very simple) XSD type for your three inputs, in this case a simple
> sequence with minoccurs and maxoccurs attributes set to 1. I would
> definitely start with WSDL in any case, given that the WSDL defines whether
> your service is WS-I compliant. HTH, Tom
