On 9/5/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > On 9/5/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > > > Note that we have a similar issue that I'm looking at under the > > wsdl2java tooling, described in this post [1] > > > > [1] > http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg22726.html > > > > On 9/5/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > 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] > > > > > > > > > > > > -- > > Luciano Resende > > Apache Tuscany Committer > > http://people.apache.org/~lresende <http://people.apache.org/%7Elresende > > > > http://lresende.blogspot.com/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > So several points coming out here. Let me try and catch them (in no > particular order) > > Issue1 - we have more than one piece of code in Tuscany that generates > WSDL > (using underlying Axis2 tools but possibly in different ways) > Solution > Do WSDL generation in one place. > > Issue2 - The WSDL that is generated doesn't match the JAX-WS definition of > wrapped which we have set out to support > Solution1 > get Axis to fix it > Solution2 (stop gap) > post process the generated WSDL to correct it for Tuscany > > Issue3 - Service providers and consumer outside of Tuscany may generate > broken WSDL and reasonably expect their messages to work with Tuscany > Solution > There is a fix available to make inbound Axis2 processing lax to the > extent that it handlse Axis2 version of a null parameter operation > A fix is required for void return values > > It sounds like > > We could address Issue1 if it's possible > - need Luciano/Ant to say if this is possible and/or worth it > > We should address Issue2 Solution 1 > - well get it moving at least > > We could address Issue2 Solution2 > - I quite like the idea of producing the correct WSDL as we see it but > there is concern that we don't know if it we will break someone who relies > on the WSDL the way axis produces it. This makes the assumption that it > works for more people in its current form that it does in it's fixed up > form. Which in turn is based on people being happy using Axis2. Warrants a > bit of investigation. > > We should address Issue3
I agree this should be brought up with the Axis2 guys before we go ahead and try to patch the wsdl. Maybe there is some reason its this way, maybe there is some option we're not using to get the wsdl the way we want. Axis2 has passed the JAXWS TCK and its had lots of interop testing and fixing done with lots of other systems, and they are the WS experts not us. I think the ultimate goal should be for SDO to be a proper Axis2 supported data binding just as other data bindings like adb, jibx and jaxb are. That way we can just remove the tools from Tuscany and have all the code in axis2. That will make our lives much easier not having to keep copying and patching the axis2 code, and it will help encourage the use of SDO. We can't get that done by our 1.0 though so need something for now. We're not planing on attempting to pass the jaxws tck so i'd be happy if we just have something that works even if we suspect it may not be fully jaxws compliant as long as Tuscany services and references can talk to each other or to native axis2 clients and services. So i still quite like the fix that Simon L proposed early on in this thread. ...ant
