My comments between <rjb></rjb> below... Russell Butek [EMAIL PROTECTED]
Tom Jordahl <[EMAIL PROTECTED]> on 05/07/2002 10:57:46 AM Please respond to [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: RE: Revamped WSDL2Java framework Comments: I like the idea of moving the Symbol table to its own package. This will make it easier to move toward a true XML Schema parser which is separate from the WSDL symbol table. <rjb>Well... I wouldn't agree to separate symbol tables. I envision an XML symbol table which is extended by a WSDL symbol table. In any case, separating these WILL make it easier.</rjb> It also is nice and clean that the Writer classes are grouped together I am not a big fan of moving things to the org.apache.wsdl package. I believe for the time being it should stay under the axis package. <rjb> Why? This could conceivably move outside of AXIS. If we did this now, we wouldn't have to rename it again. Of course if it DOES move we'd probably have to give it a slightly different name anyway! Any suggestions? We've already kinda overused the wsdl subpackage. org.apache.axis.wsdlbase? </rjb> I am not clean on what the WSDL2 class is/does. Is it a real user entry point? A better name would help, but why would you want to build a symbol table and do nothing with it? Testing? <rjb> I was hoping someone would come up with a better name. I came up (rather lamely, I admit) with WSDL2 because that implies that it's the front end for WSDL2Java, WSDL2COBOL, WSDL2XXX, etc. I guess we COULD just call it WSDL.java. This class doesn't really need a main method, but the method IS useful when you want to verify WSDL without generating anything. </rjb> I have concerns that anyone using our emitter API will be unable to seamlessly upgrade their axis jar file to use the latest version. Macromedia has several projects that use WSDL2Java, and they use the Emitter class (as was originally intended), not the command line WSDL2Java class. <rjb> Valid point. However, we've been changing all sorts of other things in AXIS without asking this question (and breaking a lot of IBM code in the process, by the way), so it's rather restrictive asking it here. The extensions we have in IBM are able to change all references of Emitter to WSDL2Java (or WSDL2, depending on which level is being coded to). (For consistency I have changed some of the accessor method names. If this is a problem I can easily change them back). I personally think that this comes down to a philosophical question. Should ALL API's to the tool - command line and programmatic - be in the same file or should the command line API be in a different file? It's clear you and I are in opposite camps. Perhaps we should put this to a vote. If different files wins, then most of WSDL2 becomes the Emitter base class and most of WSDL2Java becomes an Emitter extension. I personally don't think these extra classes are necessary. </rjb> And finally, playing Devils advocate, do we really need to do this? Are there users clamoring for an extensible architecture for the emitter that isn't even complete yet? <rjb> Yes. IBM. That's why I'm doing it. And a couple folks on axis-user have complained that extending the current model is messy. One problem is all the Java-isms in the WSDL2 framework (primarily in SymbolTable). I've moved most of these, though there are still some that need moving. Another is the complexity of extending the current model. Everything is in a single directory so it's not really clear WHAT's being extended or what needs to be extended. You can see by my examples that some of this complexity is cleared up. I fully intend to write a little primer for folks that want to extend this stuff. </rjb> -- Tom Jordahl Macromedia -----Original Message----- From: Russell Butek [mailto:[EMAIL PROTECTED]] Sent: Monday, May 06, 2002 3:41 PM To: [EMAIL PROTECTED] Subject: Re: Revamped WSDL2Java framework Do folks think this is a reasonable revamp? I haven't heard from anyone except dims, and dims (except for a couple bugs he found) is OK with it. My next question is packaging. I packaged it like I did to avoid interfering with the existing emitter code. But if I replace the existing code with the new stuff I'd rather do something a bit more sensible. We have 3 items: 1. symbol table classes 2. framework classes 3. WSDL2Java implementation classes Here's my proposal: 1. org.apache.wsdl.symbolTable 2. org.apache.wsdl 3. WSDL2Java.java in org.apache.axis.wsdl (like it is now) and the rest in org.apache.axis.wsdl.toJava A question is, CAN I even put 1 & 2 where I suggest? It pulls them out of the axis subpackage, but they're logically outside of AXIS anyway. Russell Butek [EMAIL PROTECTED] Russell Butek/Austin/IBM@IBMUS on 05/03/2002 01:48:32 PM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Revamped WSDL2Java framework Back before beta 2 I said I wanted to revamp the WSDL2Java framework for better extensibility. Well, here's my first stab at it: (See attached file: WSDL2.zip). You should be able to plunk this into an existing build and build it (at least it works for me). Everything's new except some tweaks I did to test/utils/TestSrcContext.java and test/wsdl/Wsdl2javaAntTask.java that I had to make to get a build to use this version of WSDL2Java rather than the original. Those of you that might be interested (Tom, Rich, dims), please take a look at this note and let me know if these changes are worthy to commit (and where best to commit them). I've rearranged things: 1. org.apache.axis.wsdl2.st contains the symbol table classes 2. org.apache.axis.wsdl2 contains the writer framework 3. org.apache.axis.wsdl2.java contains the WSDL2Java extension to the writer framework I'm not particularly fond of these new package names or class names. I just wanted to put them somewhere without affecting the existing code. The important point is that there are 3 packages: 1 and 2 could conceivably be pulled into a separate project. 3 is the only package that really must stay inside AXIS. Some notes. - "java org.apache.axis.wsdl2.WSDL2 <wsdlFile>" will populate the symbol table, doing any validation checks along the way. It doesn't generate anything. - "java org.apache.axis.wsdl2.java.WSDL2Java <wsdlFile>" functions just like org.apache.axis.wsdl.WSDL2Java. - I got rid of Emitter. That class had some stuff that belonged in the framework and some stuff that belonged in the WSDL2Java extension. The hidden function moved into SymbolTable and the exposed stuff (option accessors) moved to WSDL2 and its extension WSDL2java. - WSDL2 is the parser front end framework. WSDL2, Writer, and WriterFactory are what extenders extend. - There are still some Java-isms that I've got to remove from the framework, but I managed to move most of them to the WSDL2Java package. - A particularly handy hook for extending WSDL2Java is JavaWriterFactory.addWriter(<WSDL type class>, <writer class>). I like that API, but I'm not sure about the best way to implement it (on JavaWriterFactory or way back on WSDL2?), so right now the implementation for it is just a hack to support my extension example (see next bullet). I'd like to hear your thoughts on this. I could leave it on JavaWriterFactory, which means it's part of WSDL2Java extensions only. Or I could move it to WSDL2, which means ALL extensions (including WSDL2Java) would use it. A couple points about moving it to WSDL2: 1. We could possibly get rid of the Java WSDL writers (JavaBindingWriter, JavaServiceWriter, etc) and add the file writers directly. 2. If we get rid of the intermediate writer classes, their logic would have to move somewhere. So the file writers would probably get more complex. - Here are a couple examples of extending WSDL2Java: (See attached file: examples.zip). They both generate everything WSDL2Java does today, but they also generate a file containing a list of service ports. example1 is an extension of the existing WSDL2Java. example2 is an extension of my new stuff. You can see the new extension is about half the old one. By the class names you can see I intend to add some documentation to the integration guide once I get the new implementation in place. This whole thing deserves (and has from the beginning!) more description than this little note, and it will get it (in the integration guide) once we decide on the proper direction. But for now, please ask me anything that you're puzzled about. Russell Butek [EMAIL PROTECTED]
