axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "R J Scheuerle Jr" <>
Subject Re: Revamped WSDL2Java framework
Date Tue, 07 May 2002 18:40:21 GMT
Great job Russell.

Here are some points that I think are worth considering.

1) The WSDL2 parser may be used for more than a front-end of an emitter. 
In fact, I have a "query" tool that uses the current WSDL2Java front-end 
to load and process the wsdl and the "back end writers" build up 
information that I can query via API.  You could also think of the runtime 
that uses the WSDL2 parser front-end to do auto-deployment of artifacts 
(i.e. type mappings) on the back-end.  In these cases the term "Writer" is 
a misnomer, since nothing is written.  Could we decide on a different name 

2) Also please consider the apparent one-to-one relationship between 
Writers and files.  For a C++ back-end, it may be proper to have the 
backend generate all the type implementations into a single cpp file.  Or 
perhaps the writer is invoked with a output .h and .cpp file ?  Right now 
the JavaWriter accepts a bunch of parameters associated with the file 
name.  Perhaps all of the file specific information should be removed from 
the constructor, and instead the constructor should receive a PrintWriter 
(which could be a new PrintWriter or shared with other Writers). 

Rich Scheuerle
XML & Web Services Development
512-838-5115  (IBM TL 678-5115)

Russell Butek/Austin/IBM@IBMUS
05/06/2002 02:40 PM
Please respond to axis-dev

        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. in org.apache.axis.wsdl (like it is now) and the rest 

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

Russell Butek/Austin/IBM@IBMUS on 05/03/2002 01:48:32 PM

Please respond to

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:  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/ and
test/wsdl/ 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 
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. contains the symbol table classes
2.  org.apache.axis.wsdl2 contains the writer framework
3. 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 
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
- "java <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
- Here are a couple examples of extending WSDL2Java:  (See attached file:  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 
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

View raw message