axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject RE: Revamped WSDL2Java framework
Date Tue, 07 May 2002 21:25:21 GMT

I can see this going either way, but here are my two reasons for keeping them separated:

1) We've already got people out there (Macromedia for sure, and I bet there are others) using
Emitter as the programatic API.  Even if we end up voting to make it go away, we will want
to keep the class around and deprecate it (at least through 1.0, I should think).

2) I really like the idea of having an Emitter with a SINGLE concept of "configuration", which
is controllable via APIs.  Then we cleanly split out the command-line option processing and
the config file processing into a separate class or classes, and design the Emitter to do
what it does and nothing more.  This is plain old good OO design.

More inline below.  Perhaps a vote is in order here after some consideration by the team.


> -----Original Message-----
> From: Russell Butek []
> Sent: Tuesday, May 07, 2002 4:26 PM
> To:
> Subject: RE: Revamped WSDL2Java framework
> Here are my comments about whether to have WSDL2Java (command 
> line APIs)
> AND Emitter (programmatic APIs), or just WSDL2Java (command line and
> programmatic APIs in the same place).  Tom, Glen, I'm writing 
> this here
> rather than on the chat so that I can present an organized set of
> arguments.  For those who haven't been on the chat, I'm 
> arguing for all
> APIs in the same class.  Why?
> 1.  If I'm a WSDL2Java command line user, and I now want to 
> be able to call
> WSDL2Java programmatically, the WSDL2Java class is the most 
> obvious place
> to look.  Otherwise I have to guess where in the 
> documentation to look for
> what to call.

So the JavaDocs for WSDL2Java indicate that this is the command line driver for Emitter. 
No problem.

> 2.  If I, as a WSDL2Java developer, want to change the API, if we have
> theAPI's in 2 files, it's a bit easier to add it to the 
> programmatic API
> and forget the command line API (this HAS happened here in AXIS).  If
> they're both in the same file, it's a good hint that you have 
> to change
> them both.

It's just as easy to make API changes and forget to change the command-line processing/main()
in the same class, I think.  (lord knows I've seen this happen in single-class designs like
this too :))

> 3.  If/when we add, this is a 3rd type 
> of API.  What
> does the file look like?  Like the command line args, most 
> likely.  Where
> does the processing belong?  WSDL2Java?  Emitter?  What's the 
> precedence?
> My suggestion is, command-line or accessors take precedence 
> over wsdl2java.
> properties.  To get the proper precedence and to make sure
> is always processed, this processing must go into
> Emitter.  But if the format is like the command line args, it 
> would be best
> to have it in WSDL2Java since we already know how to process 
> command line
> args there.  If everything were in the same place, then we 
> can process it
> all together.

This is sort of a separate issue, but I think the properties file is really to make life easier
for the command line user.  Other programatic uses are probably going to have their own configuration
needs, which is another reason I like the idea of keeping it cleanly separated.

You can think of it (or at least I think of it) like this.

<Config Source> -> <Emitter> -> <output>

The Emitter just has APIs on it for configuration.  The Config Source is something like WSDL2Java
which processes command line options and calls Emitter APIs.  If you want to pull out properties-file
handling into another class which can be used by both WSDL2Java and some other programatic
user of Emitter, that's fine too.  Or you can script Emitter however you want.  Just seems
to make more sense to me than tying everything together - why force the classloader to load
the command-line processing stuff if you're a programatic user?

View raw message