axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <gdani...@macromedia.com>
Subject RE: Revamped WSDL2Java framework
Date Wed, 08 May 2002 02:26:59 GMT

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

--Glen

Mime
View raw message