axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nadir amra (JIRA)" <>
Subject [jira] Commented: (AXIS2-3724) WSDL complex type elements do not comply to JAXB Java bean
Date Wed, 27 May 2009 18:51:45 GMT


nadir amra commented on AXIS2-3724:

So is this going to be fixed anytime soon?  Or can someone describe the fix and point me to
the files so I can take a look and possibly fix?

> WSDL complex type elements do not comply to JAXB Java bean
> ----------------------------------------------------------
>                 Key: AXIS2-3724
>                 URL:
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: wsdl
>    Affects Versions: nightly
>         Environment: Win XP Pro, JDK6_04, Tomcat 5.5.26, JAXB 2.1.6
>            Reporter: Glen Verran
>             Fix For: nightly
> I created a web service which contains one method.  It has one parameter of type RetrieveConfigurationDataRequest
and returns RetrieveConfigurationDataResponse.
> Focusing on RetrieveConfigurationDataRequest , the java bean was generated by JAXB 2.1.6.
 Here are the variables from the java bean below
>     @XmlElement(required = true)
>     protected String echoData;
>     @XmlElement(required = true)
>     protected String identifierType;
>     @XmlElement(required = true)
>     protected String identifier;
>     @XmlElement(required = true)
>     protected String revision;
>     protected String vintage;
>     protected Long dataBlockSize;
>     protected Long dataBlockPosition;
>     @XmlElement(required = true)
>     protected DataEncodingType dataEncodingType;
> The order of their "getters" and "setters" appear in the same order as the variables.
> The WSDL that gets generated contains this complexType which lools like this.
> <xs:complexType name="RetrieveConfigurationDataRequest">
>   <xs:complexContent>
>     <xs:extension base="ns0:JaxbInternalMsg">
>       <xs:sequence>
>         <xs:element minOccurs="0" name="dataBlockPosition" nillable="true" type="xs:long"/>
>         <xs:element minOccurs="0" name="dataBlockSize" nillable="true" type="xs:long"/>
>         <xs:element minOccurs="0" name="dataEncodingType" nillable="true" type="ax21:DataEncodingType"/>
>         <xs:element minOccurs="0" name="echoData" nillable="true" type="xs:string"/>
>         <xs:element minOccurs="0" name="identifier" nillable="true" type="xs:string"/>
>         <xs:element minOccurs="0" name="identifierType" nillable="true" type="xs:string"/>
>         <xs:element minOccurs="0" name="revision" nillable="true" type="xs:string"/>
>         <xs:element minOccurs="0" name="vintage" nillable="true" type="xs:string"/>
>       </xs:sequence>
>     </xs:extension>
>   </xs:complexContent>
> </xs:complexType>
> I find that the WSDL does not comply with the JAXB 2.1.6 generated java bean in the following
> 1)  The elements are alphabetically sorted and do not appear in the same order as in
the java bean. 
> 2)  Look at the "identifier" element  and you'll see that it has a minOccurs of 0.  This
is a required field by the java bean and so should not have a minOccurs modifier in there.
> 3)  I also noticed that all the fields are set to nullable.  I don't know what the criteria
is for this, but I assume it is because these are referring to java objects and not primitives.
 I also think that if an object is required, that it should not be nullable.
> At the end of the day, the WSDL must take JAXB and its annotations into account and reflect
the web service and its java beans 100% and it is not doing that.
> I know there is a workaround by inserting a modified wsdl into the aar file, but I don't
want to have to do that since AXIS2 was designed to generate the WSDL itself when issuing
?WSDL in a browser.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message