[
https://issues.apache.org/jira/browse/CXF-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518056
]
jimma commented on CXF-815:
---------------------------
I used WTP to validate this wsdl and schemas and I found there are some invalid
schemas are imported or referenced by this wsdl . Below is the details :
1. In /xml/Common-CBETrouble/v1-4/OSSJ-Common-CBETrouble-v1-4.xsd:
Error message : The {type,definition} of element
'troubleTicketStateState' is not validly derived from the {type,definition} of
the substitutionHead 'cbetrouble-v1-4:baseTroubleTicketState'
2. In /xml/Common-CBEParty/v1-4/OSSJ-Common-CBEParty-v1-4.xsd
Error message: The {type,definition} of element 'stateState' is not
validly derived from the {type,definition} of the substitutionHead
'cbeparty-v1-4:baseState'
3 . In /xml/Common-CBEBi/v1-4/OSSJ-Common-CBEBi-v1-4.xsd
Error message: The {type,definition} of element 'interactionStateState'
is not validly derived from the {type,definition} of the substitutionHead
'cbebi-v1-4:baseInteractionState'
When pass these invalid schemas to JAXB, JAXB will be hanging . I will report
this issue to JAXB guys.
After I fix these errors by remove the "type" attribute or "substitutionGroup"
attribute for these elements and it can generate code for it quickly.
> wsdl2java compiler gets stuck in a loop on complex XML schemas
> --------------------------------------------------------------
>
> Key: CXF-815
> URL: https://issues.apache.org/jira/browse/CXF-815
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 2.0-RC, 2.0
> Environment: Java 1.5; Windows 2003; VMware Workstation 5.5
> Reporter: Paul Hanke
> Assignee: jimma
> Priority: Minor
> Attachments: ossj-wsdl.zip
>
>
> wsdl2java compiler gets stuck in a loop on complex XML schemas. Compiled the
> WSDL for the OSS/J Common API just fine. This WSDL imports a single flat
> XSD. Next, I took the Common API WSDL as a template and started writing a
> WSDL for the OSS/J Trouble Ticket API. This WSDL imports an XSD which in
> turn imports other XSDs which in turn import other XSDs and so on (some XSDs
> are multiply imported in this dependency graph). When I tried compiling the
> Trouble Ticket WSDL, the WSDL compiler started eating up 99% of the CPU (the
> memory footprint stayed steady at roughly 50M) and showed no signs of
> stopping (I eventually terminated the process). I modified the Trouble
> Ticket WSDL, commenting out the message, port type, and binding declarations
> as well as replacing the port in the service declaration with the port type
> from the Common WSDL - this just left the XSD import statement from the
> original WSDL. I tried compiling the Trouble Ticket WSDL again, and the WSDL
> compiler still started eating up 99% of the CPU with no signs of stopping.
> As a final test, I put the Trouble Ticket WSDL back the way I initially had
> it and ran it through the Axis2 WSDL compiler - the Axis2 WSDL compiler
> didn't even blink while generating all the bindings/stubs/skeletons.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
