axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fabian Christ (JIRA)" <>
Subject [jira] Commented: (AXIS2-1060) WSDL2Java: Wrong handling of elements and complexTypes
Date Mon, 04 Sep 2006 14:28:22 GMT
    [ ] 
Fabian Christ commented on AXIS2-1060:


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:
>             Project: Apache Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: wsdl
>            Reporter: Fabian Christ
>         Attachments:
> 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
> - Fabian

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message