DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22360>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22360 WSDL2Java throws emitter time out exception even though WSDL is on local disk [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |REMIND ------- Additional Comments From [EMAIL PROTECTED] 2003-08-13 16:38 ------- Glen, My WSDL, which has 5 messages in it but which imports some large schemas, takes upwards of ten minutes to generate. Once, when I was young and foolish, I tried adding many more messages using those same schema elements, and WSDL2Java happily churned away for 24+ hours before I finally killed it. I've profiled WSDL2Java extensively and have fixed a few bottlenecks where I could. However, there are some significant defects (in the sense that they hinder performance, though they do work correctly, eventually), that I can't address because they'd break backward compatibility of the emitter API, among other things. The main culprits are (1) the SymbolTable, which has inefficient data structures and which exposes those to other parts of the application in ways that thwart simple refactoring efforts; and (2) the various algorithms in SchemaUtils and Utils that perform repeated, exhaustive searches of the entire symbol table to resolve references. Personally, I think the thing to do is to scrap the schema interpreting code in axis and replace it with that provided by Xerces. Xerces' schema parser is (to be blunt) a much better design and a heck of a lot faster because it produces a proper AST for the schema rather than an inefficient table that has to be repeatedly scanned (and scanned, and scanned...). But, such a change would necessarily impact the Emitter framework in ways that would be incompatible with current code. It's a worthwhile project, but it'll make (a lot of?) people unhappy. I'm marking this as "remind" b/c the issue has morphed from "how do I set the timeout on wsdl2java" to "why is wsdl2java so slow." We answered the first question for the original submitter, and I think we know the answer to the second one too, but it remains an open issue (hence the "remind"). Feel free to re-reopen/re-size it if you like.
