Axis2 has passed the jaxws tck now so either the tck doesn't check this or
we're using java2wsdl incorrectly. If it is a bug how about tolerating this
in our code for now till Axis2 gets fixed?  I.e the apply the changes
suggested below. This seems better to me that having yet another patch to
java2wsdl in Tuscany as its becoming a maintenance nightmare with these
local changes we have making it really difficult to change Axis2 releases.

   ...ant

On 9/2/07, Simon Laws <[EMAIL PROTECTED]> wrote:
>
> On 9/2/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >
> > I don't think the Axis2 generates a valid wrapper-style WSDL in this
> case
> > (even though the WSDL itself is legal). It violates rule i & ii as it
> has
> > the input message fooMessage doesn't have any part.
> >
> > The following is quoted from the JAX-WS 2.0 spec:
> >
> > 2.3.1.2 Wrapper Style
> > A WSDL operation qualifies for wrapper style mapping only if the
> following
> > criteria are met:
> > (i) The operation's input and output messages (if present) each contain
> > only
> > a single part
> > (ii) The input message part refers to a global element declaration whose
> > localname is equal to the operation
> > name
> > (iii) The output message part refers to a global element declaration
> > (iv) The elements referred to by the input and output message parts
> > (henceforth referred to as wrapper
> > elements) are both complex types defined using the xsd:sequence
> compositor
> > (v) The wrapper elements only contain child elements, they must not
> > contain
> > other structures such as
> > wildcards (element or attribute), xsd:choice, substitution groups
> (element
> > references are not permitted)
> > or attributes; furthermore, they must not be nillable.
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message -----
> > From: "Simon Laws" <[EMAIL PROTECTED]>
> > To: <tuscany-dev@ws.apache.org>
> > Sent: Sunday, September 02, 2007 7:41 AM
> > Subject: Re: Wrapper style test in WSDL processing?
> >
> >
> > > On 8/31/07, Simon Laws <[EMAIL PROTECTED]> wrote:
> > >>
> > >>
> > >>
> > >> On 8/31/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > The operation.getInput() cannot be null to qualify for the wrapper
> > >> > style.
> > >> > There must be a part in the input message corresponding to the
> > >> > operation
> > >> > name:
> > >> >
> > >> > input
> > >> >     --- message
> > >> >         --- part (only one part)
> > >> >                 --- element (the element name should be the same as
> > the
> > >> > operation name)
> > >> >
> > >> > The element should look like this:
> > >> >
> > >> > <element name="myMethod">
> > >> >     <complexType>
> > >> >         <sequence/> <!-- an empty sequence -->
> > >> >     </complexType>
> > >> > </element>
> > >> >
> > >> > Thanks,
> > >> > Raymond
> > >> >
> > >> > ----- Original Message -----
> > >> > From: "Simon Laws" <[EMAIL PROTECTED]>
> > >> > To: "tuscany-dev" <tuscany-dev@ws.apache.org>
> > >> > Sent: Friday, August 31, 2007 10:34 AM
> > >> > Subject: Wrapper style test in WSDL processing?
> > >> >
> > >> >
> > >> > > There is a test to determine whether a WSDL operation follows the
> > >> > > "wrapped"
> > >> > > style in accordance with JAX-WS 2.0 spec.  See
> > >> > > WSDLOperationIntrospectorImpl
> > >> > > (
> > >> > >
> > >> >
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/interface-wsdl/src/main/java/org/apache/tuscany/sca/interfacedef/wsdl/impl/WSDLOperationIntrospectorImpl.java
> > >> > > )
> > >> > >
> > >> > > The code is currently
> > >> > >
> > >> > >    public boolean isWrapperStyle() throws InvalidWSDLException {
> > >> > >        if (wrapperStyle == null) {
> > >> > >            wrapperStyle =
> > >> > >                wrapper.getInputChildElements() != null && (
> > >> > > operation.getOutput() == null || wrapper
> > >> > >                    .getOutputChildElements() != null);
> > >> > >        }
> > >> > >        return wrapperStyle;
> > >> > >    }
> > >> > >
> > >> > > Which doesn't seem to cater for the case where there may be no
> > input
> > >> > > parameters. I'm diving into this code now to see if I can work
> out
> > >> > what it
> > >> > > means but if anyone has any insight I would appreciate it.
> > >> > >
> > >> > > Needless to say I have a scenario where I am trying to auto
> > generate
> > >> > WSDL
> > >> > > for a method with the signature
> > >> > >
> > >> > > String myMethod()
> > >> > >
> > >> > > And it's complaining that it's not wrapped.
> > >> > >
> > >> > > Simon
> > >> > >
> > >> >
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> > For additional commands, e-mail: [EMAIL PROTECTED]
> > >> >
> > >> > What you are saying sounds right to me, I.e. you can validly have
> no
> > >> parameters in your method but in this case it should build an empty
> > >> sequence
> > >>
> > >>
> > >> <element name="myMethod">
> > >>     <complexType>
> > >>         <sequence/> <!-- an empty sequence -->
> > >>     </complexType>
> > >> </element>
> > >>
> > >> And have this as the single input type. I'm deeper into the code now
> > >> looking for why this isn't the case.
> > >>
> > >> Thanks Raymond
> > >>
> > >> Simon
> > >>
> > > 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>
> > >
> > > So in our code when it comes to testing for wrapped it returns false
> > > because
> > > this doesn't match the algorithm that was presented earlier in this
> > > thread,
> > > i.e. there is no part of the input message corresponding to the
> message
> > > name. So when you try this in Tuscany is throws an exception saying
> that
> > > the
> > > operation is not wrapped.
> > >
> > > It would be inconvenient for us to not support operations with no
> > > parameters. As the wsdl generation process assumes that the target
> > > operations will be generated as wrapped operations here's what I did..
> > >
> > > 1/ Changed the isWrapperStyle  test (in WSDLOperationIntrospectorImpl)
> > to
> > > read.
> > >
> > >    public boolean isWrapperStyle() throws InvalidWSDLException {
> > >        if (wrapperStyle == null) {
> > >            wrapperStyle =
> > >
> > > (operation.getInput().getMessage().getParts().values().size()
> > > == 0 ||wrapper.getInputChildElements() != null) &&
> > >                (operation.getOutput() == null ||
> > > wrapper.getOutputChildElements() != null);
> > >        }
> > >        return wrapperStyle;
> > >    }
> > >
> > > I.e. I'm letting it pass if there are no input parts at all which I
> > > believe
> > > is valid according the the JAX-WS 2.0 spec
> > >
> > > 2/ Fixed the getWrapperInfo method to take account of the case where
> > there
> > > are no input params
> > >
> > >                if (in != null) {
> > >                    for (XmlSchemaElement e : getInputChildElements())
> {
> > >                        inChildren.add(getElementInfo(e));
> > >                    }
> > >                }
> > >
> > > 3/ Fixed the Axis2 binding to properly deal with the case when no
> > > parameters
> > > are present in Axis2ServiceInOutSyncMessageReceiver.
> > >
> > >    public void invokeBusinessLogic(MessageContext inMC, MessageContext
> > > outMC) throws AxisFault {
> > >        try {
> > >            OMElement requestOM = inMC.getEnvelope
> > > ().getBody().getFirstElement();
> > >            Object[] args = null;
> > >
> > >            if (requestOM != null) {
> > >                args = new Object[] {requestOM};
> > >            }
> > >
> > > The Axis2ServiceInMessageReceiver needs the same fix if we go with
> this.
> > >
> > > This works with the forward message relying on the soap action to
> > > indentify
> > > the correct operation.
> > >
> > > I haven't checked this in as the code seems to have been carefully
> > crafted
> > > to assume that there will always be an input parameter. Can someone
> > > explain
> > > why this is thought to be the case?
> > >
> > > Regards
> > >
> > > Simon
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > Mmm, I think I'm interpreting the "(if present)" wrongly then. Anyhow it
> still leaves us with a bit of a problem. I just gave it a spin in
> Axis2-1.3.
> and get the same result so we will likely have to do our own fix in the
> short term.
>
> Simon
>

Reply via email to