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

JavaToWs generates wrong types for arrays and generic types in wrapper classes

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

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.1.1, 2.0.8
    • 2.0.9, 2.1.3
    • Tooling
    • None
    • WinXP, Sun JDK 1.5.0_10

    Description

      I found a problem where wsdl2java generates wrong types for fields in my request-wrapper classes.
      This seems to happen on Arrays of primitive types and for generic types like List<Long>.

      I have done the following:

      • Used the Java first approach and wrote an annotated interface, e.g.

      public interface MyWebServiceInterface

      { @WebMethod(action = "storeDocument") public abstract PostStageItem storeDocument( @WebParam(name="receivers") List<Long> receivers, @WebParam(name="item") PreStageDocument item, @WebParam(name="binaryContent") byte[] binaryContent, @WebParam(name="fileName") String fileName) }
      • used JavaToWS as follows:

      <java classname="org.apache.cxf.tools.java2ws.JavaToWS" fork="true">
      <arg value="-o"/>
      <arg value="src/ws/META-INF/wsdl/MyWebService.wsdl"/>
      <arg value="-databinding"/>
      <arg value="jaxb"/>
      <arg value="-wsdl"/>
      <arg value="-wrapperbean"/>
      <arg value="-verbose"/>
      <arg value="-s"/>
      <arg value="src/ws"/>
      <arg value="com.mycompany.mywebservice.MyWebServiceInterface"/>
      <classpath>
      <path refid="cxf.classpath"/>
      </classpath>
      </java>

      The result is that JavaToWS generates the WSDL as I would expect.
      But the tool fails to generate the request-wrapper classes. But the output is wrong like that:

      ...
      @XmlRootElement(name = "storeDocument", namespace = "http://www.mycompany.com/myservice")
      @XmlAccessorType(XmlAccessType.FIELD)
      @XmlType(name = "storeDocument", namespace = "http://www.mycompany.com/myservice", propOrder =

      {"receivers","item","binaryContent","fileName"}

      )
      public class StoreDocument {

      @XmlElement(name = "receivers")
      private java.lang.Long receivers;
      @XmlElement(name = "item")
      private abaxx.postbox.staging.PreStageDocument item;
      @XmlElement(name = "binaryContent")
      private PreStageDocument binaryContent;
      @XmlElement(name = "fileName")
      private java.lang.String fileName;

      ... <the getters and setters>...
      }

      This output is really unexpected. I would expect a List<Long> for "receivers" and a byte[] for "binaryContent".
      I debugged the problem and found it in
      http://svn.apache.org/viewvc/cxf/trunk/tools/javato/ws/src/main/java/org/apache/cxf/tools/java2wsdl/processor/internal/jaxws/RequestWrapper.java?view=markup
      In this class the types of the parameters are determined with:

      final Type[] paramClasses = method.getGenericParameterTypes();

      Later in buildFields() a loop is started for these parameters and they are analyzed.

      In my example, the type of the field "receivers" is a ParameterizedType instance (List<Long<). The code takes the first generic type argument, wich is Long, and use it as type for the property in the request wrapper. This is wrong. It should generate List<Long> instead.

      In the second case the type for the field "binaryContent" is determined as GenericArrayType. The method fails totally and uses PreStageDocument as type in the request-wrapper. This is because PreStageDocument was the last value of the "type" variable in the buildFields()loop and none of the if and else-if-conditions were true. I think this should at least throw an exception if no type for the field can be found.

      Maybe this problem also exists on the response-wrapper generator, but I didnt test this.

      Attachments

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            dkulp Daniel Kulp
            bwende Benjamin Wende
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment