Eric, I think almost everyone would like the SymbolTable and the SchemaUtils classes to be less.... painful.
There was a project by some people from Infravio (?) who were going to donate a brand new Schema parser and object model, and retrofit it in the WSDL2Java. This project was well underway quite a while ago, but I don't think we have heard from them in months. I think there are many "Better Ways" out there, with more coming all the time. I don't think anyone would shed too many tears over a replacement of our Schema stuff with something better. The problem is that even if you have a nice API/model, it still doesn't get you where you need to be. For example, WSDL2J is very nice, and we build WSDL2Java on top of it. But it didn't really give us more than a building block on which to implement. The same will hold true for a Schema parser. There is going to be a LOT of work tying that in to the emitters. In the short term, if you can make things faster in getNestedTypes() and friends, I think that would be much appreciated by all. -- Tom Jordahl Macromedia Server Development -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 11, 2003 5:23 PM To: [EMAIL PROTECTED] Subject: WSDL2Java performance Late last year I submitted some patches to make WSDL2Java run faster when large schemas are imported in a WSDL file. Those helped for a while, but now I'm running with a different data set and once again WSDL2Java takes far too long. To put this in context: after parsing, I have just over 1,000 entries in the SymbolTable [That is, 1,000 Qnames -> vectors]. The bottleneck I'm seeing, courtesy of my debugger, is in the SymbolTable, specifically in the setTypeReferences method, which uses Utils.getNestedTypes() and some ancillary SchemaUtils functions to resolve references between types (up and down). On my data set, it can run for an hour or more -- lots of recursive calls, iteration over the entire symbol table, etc. I find myself wondering if there isn't a Better Way to do this. Has anyone on the Axis team looked closely at the work that's been done with schema parsing in Xerces-J ? That gives you an AST in which the type hierarchy is already laid out, presumably because it doesn't go through the intermediate processes that WSDL2Java does (several recursive passes, including the construction of a DOM). It's possible to make simple queries of the schema and then walk up the type hierarchy from any arbitrary point. Further, the schema model produced by xerces bears all of the "facets" needed to support constraint checking (maxlength, pattern, etc) if one wanted to include such things in the generated code. Eric
