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 12:03:18 GMT
Have you looked at my WSDL2 class?  There is CLI extensibility stuff in
there to make writing command-line extensions easier.  It's all part of the
framework.  Once I break WSDL2 and Parser apart, it'll be much clearer why
WSDL2 is useful.

There IS duplicate code that ANYONE who uses a properties thingy will need.
However, I wasn't thinking too clearly when I wrote that note last night.
If we write the properties thingy properly, it's fairly minimal:
    Emitter emitter = new Emitter();
    WSDLProps props = new WSDLProps(emitter);
So I'm willing to back off of that one, too.  I will embrace your concept
of the Emitter class.

"Now.  OTHER than"  hmmm...  I have no clue what I was going to say!
Probably just an editing leftover.

Russell Butek

Glen Daniels <> on 05/07/2002 09:26:59 PM

Please respond to

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

Hi Russell!

I know this note got cut off / sent early, but I've got a couple of
responses to what's already here, so...

> 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).)

Do we really need a WSDL2 base class?  Why bother factoring this out until
we actually have a use case for something other than WSDL2Java?  The
Emitter is the important part in terms of your desired extensibility model,
I would think.

> 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?

Who said anything about duplicate code?  I was talking about a class which
processed the properties file and called appropriate Emitter APIs - you
write it once, and use it wherever you want.  I do not think this belongs
in Emitter.  My entire argument here revolves around the fact that Emitter
is a workhorse class - it has a function, which is to suck in some WSDL
from somewhere and call some Generators/Writers/whatever.  You set it up
with everything it needs and then tell it to go.  Reading in a properties
file, parsing command line options, pulling settings from environment
variables - these are all orthogonal to the real point of the class,
they're just different ways of supplying it with configuration/setup.

> 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.

That sounds like an ant property to me, not a WSDL2Java property....

> Now.  OTHER than

Looking forward to the rest tomorrow. :)


View raw message