cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Hanke (JIRA)" <>
Subject [jira] Commented: (CXF-815) wsdl2java compiler gets stuck in a loop on complex XML schemas
Date Thu, 26 Jul 2007 15:31:03 GMT


Paul Hanke commented on CXF-815:

Another data point to consider: in looking through the Java code generated by the Axis2 WSDL
compiler, I noticed some strange looking class names like "TroubleTicketState34" ... this
is in addition to another class named "TroubleTicketState" ... the latter maps to a "TroubleTicketState"
enumeration in the .xsd, whereas the former maps to a "troubleTicketState" element in the
.xsd ... there are a lot of similar artifacts arising from trying to map such upper/lower
camel case pairs onto a strictly upper camel case class naming convention.

> wsdl2java compiler gets stuck in a loop on complex XML schemas
> --------------------------------------------------------------
>                 Key: CXF-815
>                 URL:
>             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
>            Priority: Minor
>         Attachments:
> 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.

View raw message