[ http://issues.apache.org/jira/browse/AXIS2-1060?page=all ]
Fabian Christ updated AXIS2-1060:
---------------------------------
Attachment: example.zip
Hi,
this issue isn´t fixed in latest SVN. I attached a small example. The problem
is the underlying algorithm of the adb codegen.
In this example an element is defined in one XSD and the type of this element
is again defined in a second XSD. The adb codegen can´t find the type for such
an element because the algorithm handles all elements per file and does not
consider types defined in other XSD files. The codegen only looks for element
types in the same XSD!
The idea of the algorithm was not to generate code for unused types. To achieve
this aim it is insufficient to think that types which are found in one XSD and
have no corresponding element in this XSD (the same file) aren´t used. You have
to do more...
On the other hand the current algorithm generates classes for elements which
are defined in a XSD but never used by the WSDL. Perhaps you can say that those
types don´t have to be generated. But my opinion is that the codegen should
create code for all elements and types. Perhaps it can be optimized in the
future.
- 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]
