JBWS-1452 - WSDL To Java, Array unwrapping.

[dlofthouse]

Could someone please confirm for which WSDL styles we should be unwrapping arrays when an unbounded element is the only element in a complex type.

The code that handles the unwrapping is currently wrapped with this: -

if (! Constants.DOCUMENT_LITERAL.equals(style))
{
 ...
}

So perform the unwrapping for all styles except document/literal. Shouldn't this be the other way round?

[jason.greene]

This code only applies to the root level parameters on the SEI, unwrapping of arrays is also done in XSD processing. The reason it applies to rpc was to make arrays simpler from a client perspective. So the wsdl produced by java-wsdl for foo(String[] blah) would generate the same method signature on the client.

The reason its disabled for document/literal is because array unwrapping on the parameter level for a document/literal wrapped message is not needed. I'm not sure why bare was prevented as well, most likely was unintentional. I guess the reason no one complained is that using an array parameter for a bare service is probably rare.

-Jason

[dlofthouse]

Thanks for the information, I have been looking at the test case for http://jira.jboss.com/jira/browse/JBWS-732 to try and get a better understanding of the expected behaviour of array unwrapping.

I have the following defined in my WSDL: -

<types>
 <schema targetNamespace='http://test.jboss.org/ws/jbws1452/types' xmlns='http://www.w3.org/2001/XMLSchema' xmlns:soap11-enc='http://schemas.xmlsoap.org/soap/encoding/' xmlns:tns='http://test.jboss.org/ws/jbws1452/types' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'>

 <complexType name='testMethod'>
 <sequence>
 <element name='request' nillable='true' type='tns:RequestStringArray'/>
 </sequence>
 </complexType>

 <complexType name='RequestStringArray'>
 <sequence>
 <element name='TheStrings' type='string' maxOccurs='unbounded'/>
 </sequence>
 </complexType>

 <complexType name='testMethodResponse'>
 <sequence>
 <element name='result' nillable='true' type='tns:ResponseStringArray'/>
 </sequence>
 </complexType>

 <complexType name='ResponseStringArray'>
 <sequence>
 <element name='TheStrings' type='string' maxOccurs='unbounded'/>
 </sequence>
 </complexType>

 <element name='testMethod' type='tns:testMethod'/>
 <element name='testMethodResponse' type='tns:testMethodResponse'/>
 </schema>
 </types>
 <message name='TestEndpoint_testMethod'>
 <part element='ns1:testMethod' name='testMethod'/>
 </message>
 <message name='TestEndpoint_testMethodResponse'>
 <part element='ns1:testMethodResponse' name='testMethodResponse'/>
 </message>

I believe this matches the wrapped array example from the test case. The complexType 'testMethod' contains a sequence with a single element which references a complexType 'RequestStringArray' which contains a sequence that just contains the array. Using wstools the following method is generated on the SEI: -

(Packages removed for readability)

public ResponseStringArray testMethod(RequestStringArray request)
 throws RemoteException;

So the first stage of parameter unwrapping has occured but I don't think the array unwrapping has occured, I was expecting the method to look like: -

public String[] testMethod(String[] request)
 throws RemoteException;

[jason.greene]

The case in 732 is a contrived example that was made to have good coverage of jbossxb's handling of nulls and arrays.

In most cases, a document/literal wrapped wsdl will not wrap the array yet again in another element definition. Take a look at the wscompile output of testMethod(String[] request, int foo)

You should see something like this

<complexType name="testMethod">
 <sequence>
 <element name = "request" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
 <element name="foo" type="xsd:int"/>
 </sequence>
</complexType>

The only reason to create a wrapper element is to be able to have a distinction between a null array, and a null array element. Without the wrapper, as in above, this is not possible. Even so, for the purpose of simplifying the wsdl, most toolkits will make the sacrifice.

That said there is no reason to not do it for document/literal, so you can disable that check if you like.

-Jason