[ http://issues.apache.org/jira/browse/AXIS2-1060?page=comments#action_12432521 ] Fabian Christ commented on AXIS2-1060: --------------------------------------
Hi, when using the "-g" option my small example runs. Thanks! :-) Perhaps the "-g" option should become the default behavior? thanks for your help, - Fabian > WSDL2Java: Wrong handling of elements and complexTypes > ------------------------------------------------------ > > Key: AXIS2-1060 > URL: http://issues.apache.org/jira/browse/AXIS2-1060 > Project: Apache Axis 2.0 (Axis2) > Issue Type: Bug > Components: wsdl > Reporter: Fabian Christ > Attachments: example.zip > > > Hi, > given the following situation: You have your types for your WSDL defined in a > separate XSD named A.xsd. Now A.xsd includes another XSD file named B.xsd. In > A.xsd all the elements are defined which are used in the WSDL. In B.xsd all > complexTypes for those elements from A.xsd are defined. > The code generation does not support this situation and no types are found > for the elements from A.xsd. The types are generated by using OMElement for > everything that is unknown. I think this is a basic problem: > The code generator first looks for elements in a XSD file and then generates > classes for them. But if a XSD file just contains complexType definitions the > code generation does nothing. The current code generator´s algorithm is: If > there is no element in a schema then I don´t have to look at any types > because the types are never used without elements. But the elements might > have been defined at another location and this case is missing. > My proposal is to generate classes for all complexTypes which are found in a > XSD - just because you don´t know what a type is used for and from whom. > Another point is the use of redefine statements when a user wants to redefine > a complexType which is perhaps defined at another location. In this case we > also need every complexType found in any included or imported XSD. > - Fabian -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
