Jean-Sebastien Delfino wrote:
[snip]
Simon Laws wrote:
I've done a bit more investigation now. For the signature
String foo()
Axis2 Java2WSDL generates
<wsdl:types>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";
attributeFormDefault="qualified"
elementFormDefault="qualified"
targetNamespace="http://test/xsd";>
<xs:element name="fooResponse">
<xs:complexType>
<xs:sequence>
<xs:element name="return" nillable="true"
type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
</wsdl:types>
<wsdl:message name="fooMessage" />
<wsdl:message name="fooResponseMessage">
<wsdl:part name="part1" element="ns:fooResponse" />
</wsdl:message>
I'm trying to understand the overall picture before choosing a side:
- tolerate what Axis2 generates in our isWrapped() algorithm?
- or fix the WSDL after it's generated by Axis2?
I have the following two questions:
1) Is it true that the above WSDL has no chance to work at all as it
doesn't allow the "foo" operation to be sent at all (since there is no
"foo" element to carry it)?
2) Could you please paste the entire WSDL? including the generated
binding and service+port? I believe that it'll help answer question (1).
Thanks
OK, looks like the answer to your question was already in your post, I
should have read it better. In this case, it works with SOAP action.
I think it's better to tolerate that (incorrect) behavior from Axis2 for
now, as:
(a) I don't think we'll be able to patch all WSDLs that may be generated
by users with the Axis2 tools out of our control
(b) this is a workaround anyway, and a "tolerating" workaround is not
worse than a "patching" workaround, actually it is probably better as it
won't introduce any other side effects
I also think that we need to open an Axis2 JIRA to report and track this
bug.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
