You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Andreas Junghans <ju...@fh-karlsruhe.de> on 2005/01/21 12:19:43 UTC

Jagged arrays and .NET interop

Hi developers,

we have a problem with jagged arrays (arrays of arrays) and the way 
they are treated by Axis 1.2RC2 (probably also earlier versions) and 
.NET. We're using wrapped/literal style, and switching to RPC is not an 
option (actually, we're trying to switch _from_ RPC). The server is 
Java, the clients are Java and .NET.

What we're interested in is a possible fix/enhancement to wsdl2java. 
Specifically, we'd like to know if our suggested change in behaviour 
(see below) would be accepted for a public Axis release. If so, we'd 
like to produce a patch (but we need some pointers where to start; I've 
read AXIS-1615, but simple arrays actually work for us in 1.2RC2).

OK, on to the problem. Given the following Java signature:

public void test(String[][] testParam);

Axis' java2wsdl tool generates a WSDL like this:

<element name="test">
  <complexType>
   <sequence>
    <element maxOccurs="unbounded" name="in0" 
type="impl:ArrayOf_xsd_string"/>
   </sequence>
  </complexType>
</element>
<complexType name="ArrayOf_xsd_string">
  <sequence>
   <element maxOccurs="unbounded" minOccurs="0" name="item" 
type="xsd:string"/>
  </sequence>
</complexType>

When we feed that to .NET's wsdl.exe to generate a C# client class, we 
get a method signature that looks OK. However, making a call to the 
Java server fails at runtime because .NET cannot create a serializer 
(we get a misleading error message like "2jois83f.dll cannot be 
found"). We can fix this immediate problem by inserting/changing 
XmlArrayItemAttributes, but now Axis can't deserialize what .NET sends 
(there's an additional wrapper element - see below).

Now take a look at the WSDL produced by .NET when given the C# 
equivalent of the above Java signature:

<element name="test">
  <complexType>
   <sequence>
    <element minOccurs="1" maxOccurs="1" name="testParam" 
type="s0:ArrayOfArrayOfString"/>
   </sequence>
  </complexType>
</element>
<complexType name="ArrayOfArrayOfString">
  <sequence>
   <element minOccurs="0" maxOccurs="unbounded" name="ArrayOfString" 
type="s0:ArrayOfString"/>
  </sequence>
</complexType>
<complexType name="ArrayOfString>
  <sequence>
   <element minOccurs="0" maxOccurs="unbounded" name="string" 
type="string"/>
  </sequence>
</complexType>

(The above is not the actual WSDL, but a simplified version for easier 
reading - it may not be absolutely accurate, but I hope it gets the 
point across.)

You can see that the jagged array is wrapped in a separate element 
(named "testParam") and an additional complexType is inserted. If we 
modify the WSDL generated by java2wsdl to follow the same structure, we 
can:

- generate Java code with wsdl2java,
- generate a .NET client with wsdl.exe (with the correct method 
signature),
- successfully make a call from .NET to the server.

However, wsdl2java doesn't recognize the jagged array in this form and 
generates wrapper classes, so we end up with a Java signature like 
this:

public void test(test.ArrayOfArrayOf_xsd_string in0);

This would be acceptable on the server side, but it's very irritating 
when writing Java clients.

Our questions are:

- Can the classes involved in the wsdl2java generation easily (or at 
least with reasonable effort) be modified to recognize .NET-style 
jagged arrays and generate appropriate signatures?

- If so, would such a change be accepted into a public Axis release?

- Is there another way to solve the problem that we didn't see?

As mentioned, we can work on the problem and come up with a patch, 
provided we get some help from the developer community.

Best regards,

   Andreas Junghans