axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <>
Subject RE: Revamped WSDL2Java framework
Date Wed, 08 May 2002 00:59:17 GMT
Glen/Tom, I'll give in.  I'm not going to win this argument and it's not
terribly important anyway.  Tomorrow I'll rewrite WSDL2Java and run it past
you folks.  (Of course this brings up new issues.  We'll have 2 new files;
what should they be named?  WSDL2Java and Emitter are pretty clear since we
already have those.  What about the base framework?  Until I get a better
suggestion, WSDL2 (CLI) and Parser (API).)

There's one point I'm not yet willing to concede.  You bring it up below,
but I'm not quite sure the direction you're proposing.  In your previous
note you mentioned a properties processor that is called either by
WSDL2Java or by a programmatic user of Emitter.  I contend that a
properties parser should be inside Emitter.  It's a reasonable thing to
have and both WSDL2Java and WSDL2JavaAntTask would need to use it.  Why
make both of these (and any other user) write duplicate code to access the
properties processor when Emitter can hide that work from the user?

I can see a big reason for WSDL2JavaAntTask to need a properties file:
skeletons.  A properties file would be a good way to turn on or off
skeleton generation for ALL tests.

Now.  OTHER than

Russell Butek

Glen Daniels <> on 05/07/2002 04:49:17 PM

Please respond to

To:    "''" <>
Subject:    RE: Revamped WSDL2Java framework

Nelson just raised a good point on IRC, which is that one of the main
programatic users of this stuff is going to be the WSDL2JavaAntTask.  That
has its own concept of options/configuration, and has no need for the CLI
stuff, though it might optionally use the properties file if one exists
(i.e. <wsdl2java propFile="">...) - it just wants an API.
That seems, to me, to be another thing in favor of the separation of


> -----Original Message-----
> From: Glen Daniels []
> Sent: Tuesday, May 07, 2002 5:25 PM
> To: ''
> Subject: RE: Revamped WSDL2Java framework
> 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.
> --Glen
> > -----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