On 9/6/07, Simon Nash <[EMAIL PROTECTED]> wrote: > > See inline. > > Simon > > ant elder wrote: > > > 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. > > > WS-I has a fair bit of experience with interop as well, and the SCA > spec for the Web Service binding says that only WS-I compliant mapping is > supported. The input I have received from one of the WS-I Basic Profile > authors (see my post from yesterday) is that an approach that uses > soap:action to disambiguate between different operations without > parameters is not WS-I compliant. > > I agree that we have to be able to support native Axis2 interop (see my > comments below), but that's not the whole picture. > > > 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. > > > I have not suggested copying and patching the Axis2 code. There are > serious maintenance issues with this, as you point out. A postprocessing > approach (where this is practical) should be much more reliable. > > > 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 > > > I have now got my test case working to show Tuscany services and > references talking to each other using an augmented version of the > WSDL generated by Axis2 Java2WSDL (hand edited currently) with an > empty wrapper for the no parameters case. There's a small fix > needed in the databinding framework to deal with void return types > when there are no parameters. I have a patch and I'll post it soon. > > The next step is to see whether this works for Tuscany services and > references talking to native Axis2 clients and services. I'll look > into this later and post my findings tomorrow. > > Simon > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > On the basis that we may still encounter WSDL generated outside of Tuscany I have now checked the change I suggested earlier in this thread in under revision 573696 and recorded against TUSCANY-1653.
This targets specifically the case of axis2 generated wsdl for operations with no parameters. It does not address void return types. As before there are 3 changes. Two of these protect against null pointers and so should be of no consequence. The change of significance is a one line change to our isWrapped() test. This now reports true in cases which fall outside the JAXWS defintion of wrapped. Assuming it hasn't already been done I'll take the action to ask the question of the axis team what the status of their WSDL generation is w.r.tto wrapping no parameter operations. Regards Simon
