Hi, thank you for the response, I created a bug in JIRA. Antonio
On mer., 2011-07-20 at 10:13 -0400, Scott Kurz wrote: > I'm guessing this is a bug in the DOMWrapperHandler (the JAX-WS > binding.ws uses DOM as databinding). > > I don't see that the unwrapping does anything to group same-QName > elements (like we do in the OMElementWrapperHandler for AXIOM). > > Antonio, can you please open a JIRA? > > Scott > On mer., 2011-07-20 at 15:16 +0100, Mike Edwards wrote: > The WSDL PortType has a single operation "test" with an input message "test". > > The "test" input message is of type <test> - and the <test/> element is then > declared as a complex > type which is a sequence of <arg0/> elements, each of which are of type > xs:string. > > However, I note that the WSDL defines a complex type called "stringArray", > which is a sequence of > <item/> elements of type xs:string. > > I strongly suspect that the <test/> element SHOULD have a single <arg0/> > element of type > "stringArray" - otherwise why define the stringArray type at all. > > Certainly, the WSDL is telling the binding code to expect a string rather > than a stringArray, which > is very likely going to cause the problem you see when you call the service. > > Since the WSDL is being generated by Tuscany, you can't just change the WSDL > to fix this. > It may be that you can add some JAXB annotations to the service interface to > get around this problem > - by making it explicit to JAXB the WSDL <-> Java behaviour you are expecting. > > > Yours, Mike. >
