On 9/5/07, ant elder <[EMAIL PROTECTED]> wrote: > > On 9/2/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > > > 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" <[email protected]> > > > > 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? > > > If there's no objections very soon then how about just doing this fix for > now so Tuscany tolerates the Axis2 way for now (and something similar for > TUSCANY-1658)? > > ...ant > I have the fix for the null parameter case sitting here on my pc so I'll commit it later if no one shouts.
Simon
