You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Daniel Kulp (JIRA)" <ji...@apache.org> on 2008/08/18 19:43:44 UTC
[jira] Resolved: (CXF-1752) JavaToWs generates wrong types for
arrays and generic types in wrapper classes
[ https://issues.apache.org/jira/browse/CXF-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-1752.
------------------------------
Resolution: Fixed
Fix Version/s: 2.1.3
2.0.9
> JavaToWs generates wrong types for arrays and generic types in wrapper classes
> ------------------------------------------------------------------------------
>
> Key: CXF-1752
> URL: https://issues.apache.org/jira/browse/CXF-1752
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 2.1.1, 2.0.8
> Environment: WinXP, Sun JDK 1.5.0_10
> Reporter: Benjamin Wende
> Assignee: Daniel Kulp
> Fix For: 2.0.9, 2.1.3
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.