[
https://issues.apache.org/jira/browse/CXF-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yoann Guerro updated CXF-4163:
------------------------------
Description:
My WSDL imports several schemas. Some schemas import/include other schemas.
Some schemas are imported/included by several schemas.
Running WSDL2java with an ant task with the following options
wsdl2java -d src -b custom.xml -exsh true -autoNameResolution -verbose
MyExample.wsdl
(custom.xml is used to disable wrapper-style)
I got several errors such as:
[java] WSDLToJava Error: Thrown by JAXB:
[java] Thrown by JAXB:
[java] 'CodeGroup' is already defined
[java] at line 175 column 2 of schema
file:.../OTA/2010B/OTA_CommonTypes.xsd
[java] (related to above error) the first definition appears here
[java] at line 45 column 2 of schema file:/.../My_CommonTypes.xsd
OTA_CommonTypes.xsd defines the following type:
<xs:attributeGroup name="CodeGroup">
...
</xs:attributeGroup>
My_CommonTypes.xsd defines the following type:
<xs:attributeGroup name="CodeGroup">
...
</xs:attributeGroup>
OTA_CommonTypes.xsd is included by a schema defining a target namespace
"http://www.opentravel.org/OTA/2003/05/OTA2010B";
My_CommonTypes.xsd is included by a schema defining a target namespace
"http://xml.example.com/MyTypes";
XML schemas as well as WSDL are valid (other frameworks generates code without
any issue - and even CXF WSDL validator returns a success) and the types should
be generated in distinct packages, therefore without any conflicts.
My assumption is that CXF wsdl2java fails at resolving the type namespace with
schemas which are chameleon schemas (no targetNamespace attributes) which is
the case for all OTA type schemas.
A work-around that I would like to avoid as I'm exposing the WSDL to different
clients using different frameworks and I don't want to create 1 WSDL per
framework, would be to add targetNamespace attributes to all chameleon schemas.
was:
My WSDL imports several schemas. Some schemas import/include other schemas.
Some schemas are imported/included by several schemas.
Running WSDL2java with an ant task with the following options I got several
errors such as:
[java] WSDLToJava Error: Thrown by JAXB:
[java] Thrown by JAXB:
[java] 'CodeGroup' is already defined
[java] at line 175 column 2 of schema
file:.../OTA/2010B/OTA_CommonTypes.xsd
[java] (related to above error) the first definition appears here
[java] at line 45 column 2 of schema file:/.../My_CommonTypes.xsd
OTA_CommonTypes.xsd defines the following type:
<xs:attributeGroup name="CodeGroup">
...
</xs:attributeGroup>
My_CommonTypes.xsd defines the following type:
<xs:attributeGroup name="CodeGroup">
...
</xs:attributeGroup>
OTA_CommonTypes.xsd is included by a schema defining a target namespace
"http://www.opentravel.org/OTA/2003/05/OTA2010B";
My_CommonTypes.xsd is included by a schema defining a target namespace
"http://xml.example.com/MyTypes";
XML schemas as well as WSDL are valid (other frameworks generates code without
any issue - and even CXF WSDL validator returns a success) and the types should
be generated in distinct packages, therefore without any conflicts.
My assumption is that CXF wsdl2java fails at resolving the type namespace with
schemas which are chameleon schemas (no targetNamespace attributes) which is
the case for all OTA type schemas.
A work-around that I would like to avoid as I'm exposing the WSDL to different
clients using different frameworks and I don't want to create 1 WSDL per
framework, would be to add targetNamespace attributes to all chameleon schemas.
> WSDLToJava Error: Thrown by JAXB: 'CodeGroup' is already defined ...
> OTA_CommonTypes.xsd
> ----------------------------------------------------------------------------------------
>
> Key: CXF-4163
> URL: https://issues.apache.org/jira/browse/CXF-4163
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 2.4.2, 2.5.2
> Environment: Windows XP
> Java SDK 1.6.0_26
> Eclipse IDE 3.5.2
> Reporter: Yoann Guerro
> Labels: OTA, WSDL2JAVA
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> My WSDL imports several schemas. Some schemas import/include other schemas.
> Some schemas are imported/included by several schemas.
> Running WSDL2java with an ant task with the following options
> wsdl2java -d src -b custom.xml -exsh true -autoNameResolution -verbose
> MyExample.wsdl
> (custom.xml is used to disable wrapper-style)
> I got several errors such as:
> [java] WSDLToJava Error: Thrown by JAXB:
> [java] Thrown by JAXB:
> [java] 'CodeGroup' is already defined
> [java] at line 175 column 2 of schema
> file:.../OTA/2010B/OTA_CommonTypes.xsd
> [java] (related to above error) the first definition appears here
> [java] at line 45 column 2 of schema file:/.../My_CommonTypes.xsd
> OTA_CommonTypes.xsd defines the following type:
> <xs:attributeGroup name="CodeGroup">
> ...
> </xs:attributeGroup>
> My_CommonTypes.xsd defines the following type:
> <xs:attributeGroup name="CodeGroup">
> ...
> </xs:attributeGroup>
> OTA_CommonTypes.xsd is included by a schema defining a target namespace
> "http://www.opentravel.org/OTA/2003/05/OTA2010B";
> My_CommonTypes.xsd is included by a schema defining a target namespace
> "http://xml.example.com/MyTypes";
> XML schemas as well as WSDL are valid (other frameworks generates code
> without any issue - and even CXF WSDL validator returns a success) and the
> types should be generated in distinct packages, therefore without any
> conflicts.
> My assumption is that CXF wsdl2java fails at resolving the type namespace
> with schemas which are chameleon schemas (no targetNamespace attributes)
> which is the case for all OTA type schemas.
> A work-around that I would like to avoid as I'm exposing the WSDL to
> different clients using different frameworks and I don't want to create 1
> WSDL per framework, would be to add targetNamespace attributes to all
> chameleon schemas.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
