Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-2005

Missing type in generated WSDL part definition when using int[] arrays with RPC/Literal encoding

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1.3
    • Fix Version/s: 2.1.4
    • Component/s: None
    • Labels:
      None
    • Environment:

      java version "1.6.0_11", apache-cxf-2.1.3 (with asm-2.2.3)

      Description

      CXF seems to generate an incorrect WSDL when using operations with int[] array parameters in web services using the RPC/Literal encoding. The following code

      @WebService(name="MathService", targetNamespace="http://test.backoffice.ciss.lu/service")
      @SOAPBinding(style=SOAPBinding.Style.RPC, use=SOAPBinding.Use.LITERAL)
      public interface MathService {

      @WebMethod(operationName="ConvertToString")
      @WebResult(name="stringNumbers")
      public String[] convertToString(@WebParam(name="intNumbers") int[] numbers);
      }

      generates the WSDL code (extract):

      <wsdl:types>
      <xs:schema attributeFormDefault="unqualified" elementFormDefault="unqualified" targetNamespace="http://jaxb.dev.java.net/array" xmlns="http://jaxb.dev.java.net/array" xmlns:xs="http://www.w3.org/2001/XMLSchema">
      <xs:complexType final="#all" name="stringArray">
      <xs:sequence>
      <xs:element maxOccurs="unbounded" minOccurs="0" name="item" nillable="true" type="xs:string"></xs:element>
      </xs:sequence>
      </xs:complexType>
      </xs:schema>
      </wsdl:types>

      <wsdl:message name="ConvertToString">
      <wsdl:part name="intNumbers">
      </wsdl:part>
      </wsdl:message>
      <wsdl:message name="ConvertToStringResponse">
      <wsdl:part name="stringNumbers" type="ns1:stringArray">
      </wsdl:part>
      </wsdl:message>

      As you can see, the type information is missing in the first <wsdl:part> tag. The incorrect WSDL obviously produces errors, e.g. when generating the client using the wsdl2java tool:

      Loading FrontEnd jaxws ...
      Loading DataBinding jaxb ...
      wsdl2java -client -verbose http://localhost:8080/CISS_BackOfficeTemplate/services/MathService?wsdl
      wsdl2java - Apache CXF 2.1.3

      WSDLToJava Error:
      Summary: Failures: 1, Warnings: 0

      <<< ERROR!
      The part does not have a type defined. Every part must specify a type from some
      type system. The type can be specified using the built in element or type attrib
      utes or may be specified using an extension attribute.

      org.apache.cxf.tools.common.ToolException:
      Summary: Failures: 1, Warnings: 0

      <<< ERROR!
      The part does not have a type defined. Every part must specify a type from some
      type system. The type can be specified using the built in element or type attrib
      utes or may be specified using an extension attribute.

      at org.apache.cxf.tools.validator.internal.WSDL11Validator.isValid(WSDL11Validator.java:136)
      at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:201)
      at org.apache.cxf.tools.wsdlto.frontend.jaxws.wsdl11.JAXWSDefinitionBuilder.validate(JAXWSDefinitionBuilder.java:61)
      at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:133)
      at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:232)
      at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:83)
      at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:103)
      at org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:173)

      The error does not occur when using the (default) Document/Literal encoding or when using Integer[] arrays or List<Integer>. It is possible that the error exists with other primitive types (long, double, etc.) but I haven't tested them.

        Attachments

          Activity

            People

            • Assignee:
              dkulp Daniel Kulp
              Reporter:
              pierrepost Pierre Post

              Dates

              • Created:
                Updated:
                Resolved:

                Issue deployment