[jira] Commented: (AXIS2-3724) WSDL complex type elements do not comply to JAXB Java bean
[ https://issues.apache.org/jira/browse/AXIS2-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12713688#action_12713688 ] 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: https://issues.apache.org/jira/browse/AXIS2-3724 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 ways: 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.
[jira] Commented: (AXIS2-3724) WSDL complex type elements do not comply to JAXB Java bean
[ https://issues.apache.org/jira/browse/AXIS2-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588507#action_12588507 ] Glen Verran commented on AXIS2-3724: It seems that using this Dispatcher method is a workaround. Are there plans in the pipeline that Axis2 will fully support and comply with JAXB2.x java beans natively without having to write a dispatcher? WSDL complex type elements do not comply to JAXB Java bean -- Key: AXIS2-3724 URL: https://issues.apache.org/jira/browse/AXIS2-3724 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 ways: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3724) WSDL complex type elements do not comply to JAXB Java bean
[ https://issues.apache.org/jira/browse/AXIS2-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587573#action_12587573 ] Glen Verran commented on AXIS2-3724: dims, How can this be achieved? FYI, I used the nighly build of the 9th of April. i tested this yesterday. WSDL complex type elements do not comply to JAXB Java bean -- Key: AXIS2-3724 URL: https://issues.apache.org/jira/browse/AXIS2-3724 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 ways: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3724) WSDL complex type elements do not comply to JAXB Java bean
[ https://issues.apache.org/jira/browse/AXIS2-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587575#action_12587575 ] Davanum Srinivas commented on AXIS2-3724: - See jaxws-addressbook sample specifically the readme WSDL complex type elements do not comply to JAXB Java bean -- Key: AXIS2-3724 URL: https://issues.apache.org/jira/browse/AXIS2-3724 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 ways: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (AXIS2-3724) WSDL complex type elements do not comply to JAXB Java bean
[ https://issues.apache.org/jira/browse/AXIS2-3724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12587569#action_12587569 ] Davanum Srinivas commented on AXIS2-3724: - You really need to use the JAXWS 2.1 support in latest nightly. -- dims WSDL complex type elements do not comply to JAXB Java bean -- Key: AXIS2-3724 URL: https://issues.apache.org/jira/browse/AXIS2-3724 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 ways: 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
