I don't think you should put anything in org.apache.wsdl as there could be other WSDL related work in Apache .. so putting something there would imply its common to all. Clearly the emitter framework classes do not belong to that level.
So how about: 1. org.apache.wsdl.emitter.symbolTable 2. org.apache.wsdl.emitter Eventually I'd like to see the emitter be made Axis independent (and maybe JAXRPC dependent) and then for WSDL2Java to move to org.apache.wsdl.emitter as well. Sanjiva. ----- Original Message ----- From: "Russell Butek" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 07, 2002 1:40 AM 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] > > >
