In the case I'm investigating, the issue is around checking if the
wrapper style is in use for the wsdl, but the problem is that
wsdl2java generates wrong interfaces for the wsdl in question.

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
>
> Simon
>


-- 
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to