27c27 < Beta 1 Version --- > 1.0 Version 32c32,34 <
System Management --- >
Components > 38a41 >
WSDL Parser and Code Generator Framework 52a56,205 > The first subsection details a number of pluggable components in general. > More details are provided for other components in the remaining > subsections. > >

> Components

> This section describes in general how to plug specializations > of various components into AXIS. > >

> General Strategy >

> To override the default behavior for a pluggable component: >

Develop implementation of components interface

Define the implementation class to AXIS by either creating > a service definition file (prefered) > or by setting a system property. >
- PREFERED: To create a service definition file:
- Set system property: >
  - The name of the system property is the name of the interface.
  - The value of the system property is the name of the implementation.
  - The optional system property name (in table, below) may be also be used.
  - Setting a system property is not prefered, particularly in a J2EE or other application > hosting environment, because it imposes a directive across all applications. > This may or may not be appropriate behavior. > If it is to be done, it should never be done from within a Web Application at runtime. >
  >
>
>
Package the implementation class and, if used, > the service definition file in a JAR file > and/or place it where it can be picked up by a class loader (CLASSPATH).

> >

> Example 1 >

> To override the default behavior for the Java Compiler: >

An implementation of the Compiler interface is already provided for the Jikes compiler.

Create the service definition file named: >
> /META-INF/services/org.apache.axis.components.compiler.Compiler

Add the following line to the service definition file: >
> org.apache.axis.components.compiler.Jikes

Since org.apache.axis.components.compiler.Jikes > is packaged with AXIS, all that needs to be done is to ensure > that the service definition file is loadable by a class loader. >

> >

> Example 2 >

> To override the default behavior for the SocketFactory > in an environment that does not allow resources to be > located/loaded appropriately, or where the behavior > needs to be forced to a specific implementation: >

Provide an implementation of the SocketFactory interface, > for example your.package.YourSocketFactory

Set the system property named >
      > org.apache.axis.components.net.SocketFactory >
> to the value >
      > your.package.YourSocketFactory >
>
This can be done by using the JVM commandline >
      > -Dorg.apache.axis.components.net.SocketFactory=your.package.YourSocketFactory >
>
Ensure that the implementation class is loadable by a class loader. >

> >

> Reference >

> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

Component/Package	Factory	Interface	Optional System Property	Default Implementation
`org.apache.axis.components.compiler`	`CompilerFactory.getCompiler()`	`Compiler`	`axis.Compiler`	`Javac`
`org.apache.axis.components.image`	`ImageIOFactory.getImageIO()`	`ImageIO`	`axis.ImageIO`	`MerlinIO, JimiIO, JDK13IO`
`org.apache.axis.components.jms`	`JMSVendorAdapterFactory.getJMSVendorAdapter()`	`JMSVendorAdapter`		`JNDIVendorAdapter`
`org.apache.axis.components.net`	`SocketFactoryFactory.getFactory()`	`SocketFactory`	`axis.socketFactory`	`DefaultSocketFactory`
`org.apache.axis.components.net`	`SocketFactoryFactory.getSecureFactory()`	`SocketFactory`	`axis.socketSecureFactory`	`JSSESocketFactory`

> > 215,219c369,377 < How can AXIS fit into existing configuration systems? <

< Justification/Rationale - why is this plug point necessary? Spec < compliance?

org.apache.axis.EngineConfiguration

The EngineConfiguration is provided by an implementation of > the interface org.apache.axis.EngineConfigurationFactory, > which currently provides methods that return client and server > configurations. 220a379,382 >

Our focus will be how to define the implementation class for > EngineConfigurationFactory. > >

EngineConfigurationFactory factory = EngineConfigurationFactoryFinder(someContext);

EngineCongfiguration config = factory.getClientEngineConfig();

AxisClient = new AxisClient(config);

EngineConfigurationFactoryFinder(someContext)

someContext

EngineConfigurationFactoryFinder works as follows: >
>

Obtain a list of classes that implement > org.apache.axis.EngineConfigurationFactory, > in the following order: 229c421,450 < Life cycle

axis.EngineConfigFactory

> The value of the system property > org.apache.axis.EngineConfigurationFactory. >
Locate all resources named > META-INF/services/org.apache.axis.EngineConfigurationFactory. > Each line of such a resource identifies the name of a class > implementing the interface ('#' comments, through end-of-line). >
> org.apache.axis.configuration.EngineConfigurationFactoryServlet >
> org.apache.axis.configuration.EngineConfigurationFactoryDefault >

Classes implementing EngineConfigurationFactory are required to > provide the method >
>
>
> This method is called, passing someContext as the parameter. >

newFactory()

< Configuration/reconfiguration

> org.apache.axis.configuration.EngineConfigurationFactoryServlet >
newFactory(obj) is called. > If obj instanceof javax.servlet.ServletContext is true, > then an instance of this class is returned. >
The default Servlet factory is expected to function as a server > (as a client it will incorrectly attempt > to load the WSDD file client-config.wsdd > from the current working directory!). > >
The default Servlet factory will open the Web Application resource > /WEB-INF/server-config.wsdd > (The name of this file may be changed using the > system property axis.ServerConfigFile): >
- > If it exists as an accessible file (i.e. not in a JAR/WAR file), > then it opens it as a file. > This allows changes to be saved, > if changes are allowed & made using the Admin tools. >
- > If it does not exist as a file, then an attempt is made > to access it as a resource stream (getResourceAsStream), > which works for JAR/WAR file contents. >
- > If the resource is simply not available, > an attempt is made to create it as a file. >
- > If all above attempts fail, a final attempt is > made to access org.apache.axis.server.server-config.wsdd > as a data stream. >
244a513,514 >

org.apache.axis.configuration.EngineConfigurationFactoryDefault

newFactory(obj)

obj

The default factory will load the WSDD files > client-config.wsdd or server-config.wsdd, > as appropriate, from the current working directory. > The names of these files may be changed using the > system properties axis.ClientConfigFile > and axis.ServerConfigFile, > respectively. > >

Architecture > Guide

> Internationalization

> Translation

< Interfaces

AXIS makes use of the Java internationalization mechanism - > i.e., a java.util.ResourceBundle backed by a properties file - > and the java.text.MessageFormat class to substitute > parameters into the message text. 264,266c579 <

< Life cycle

"{X}"

X

< Configuration/reconfiguration

For example: myMsg00=My {0} is {1}. 278,279c600,609 <

< Default behavior if not plugged.

Translation requires creating an > alternate version of the property file provided by AXIS > for a target language. > The JavaDoc for java.utils.ResourceBundle > provides details on how to identify different property > files for different locales. > >

For details on using AXIS's internationalization tools, > see the Developer's Guide. >
282,283c612 < Example <

< Internationalization

> >

> Extending Message Files

> AXIS provides a Message file extension mechanism > that allows AXIS-based code to use AXIS message keys, > as well as new message keys unique to the extended code. > 293,297c630,639 < <
In order for readers of languages other than English to be comfortable < with AXIS, we provide a mechanism for the strings used in AXIS to be translated. < We do not provide any translations in AXIS; we merely provide a means by < which translators can easily plug in their translations. --- >
> AXIS provides pluggable interfaces for > various AXIS entities, including EngineConfigurationFactory's, > Provides, and Handlers. > AXIS also provides a variety of implementations > of these entities. > It is convenient to use AXIS source code for > such implementations as starting points for developing > extentions and customizations that fulfill the unique needs > of the end user. 299,300d640 <

< Interfaces

302,320d641 <
AXIS uses the standard Java internationalization class: PropertyResourceBundle. < To make this class easy to use, there are a number of methods on JavaUtils < that are used to get the messages within the resource bundle. <

public static java.util.ResourceBundle < getMessageResourceBundle(); <

public static String < getMessage(String key) throws java.util.MissingResourceException; <

public static String < getMessage(String key, String var) throws java.util.MissingResourceException; <

public static String < getMessage(String key, String var1, String var2) throws java.util.MissingResourceException; <

public static String < getMessage(String key, String[] vars) throws java.util.MissingResourceException; <

AXIS programmers can work with the resource bundle directly via a call < to JavaUtils.getMessageResourceBundle, < but the getMessage < methods should be used instead for two reasons: <
<

JavaUtils.getMessage("myMsg00");

JavaUtils.getMessageResourceBundle().getString("myMsg00");

Copy the AXIS source file > java/src/org/apache/axis/i18n/Messages.java > to your project/package, say > my/project/package/path/Messages.java. >

Set the package declaration in the copied file > to the correct package name. >
Set the private attribute projectName > to "my.project": > the portion of the package name that is common to your project. > projectName must be equal to or be a prefix of the > copied Messages package name. >

Create the file > my/project/package/path/resource.properties. > Add new message key/value pairs to this file. >

As you copy AXIS source files over to your project, > change the import org.apache.axis.i18n.Messages > statement to import my.project.package.path.Messages. >
Use the methods provided by the class Messages, > as discussed in the Developer's Guide, > to access the new messages. >

getMessage

--- > Behavior 333,363c683 <

< The getMessage methods

< If you have a message with no variables <

myMsg00=This is a string.

< then simply call <

JavaUtils.getMessage("myMsg00");

< <

If you have a message with variables, use the syntax "{X}" < where X is < the number of the variable, starting at 0. For example: <

myMsg00=My {0} is {1}.

< then call: <

JavaUtils.getMessage("myMsg00", < "name", "Russell");

< and the resulting string will be: "My name is Russell." <

You could also call the String array version of getMessage: <

JavaUtils.getMessage("myMsg00", < new String[] {"name", "Russell"});

< <

The String array version of getMessage < is all that is necessary, but the vast majority of messages will have 0, < 1 or 2 variables, so the other getMessage < methods are provided as a convenience to avoid the complexity of the String < array version. <

Note that the getMessage < methods throw MissingResourceException < if the resource cannot be found. And ParseException if there are < more {X} entries than arguments. These exceptions are RuntimeException's, < so the caller doesn't have to explicitly catch them. <

The resource bundle properties file is org/apache/axis/utils/resources.properties. <
--- >

Messages

resources.properties

Entries in the properties file must follow the pattern: <string><2-digit < suffix>. <

Entries should be ordered in the properties file alphabetically by key. <

Entries in the properties file must never be changed. If a code < change requires a message change, don't change the existing message; instead < create a new entry, incrementing the 2-digit suffix. This must be < done for two reasons: 1. You don't know whether the message < is being used elsewhere. 2. So the translator only has to be < aware of, and translate, the new strings. Without this restriction, < every time translators are given the properties file to translate, they < would have to translate all strings all the time. <

> Hierarchical Search

Messages

projectName

parent

Messages

Unless changed, the default behavior, meaning what happens when a key > isn't defined in the new properties file, > is to fall back to the AXIS properties file > (org.apache.axis.i18n.resource.properties). 394,411c713,714 <

< Examples

org.apache.axis.client.Call.invoke

< if ( operationName == null ) <
< throw new AxisFault( "No operation name specified" ); <

We will have to add an entry into org/apache/axis/utils/resources.properties. < Something like: <

noOperation=No operation < name specified. <

And change the code to read: <

< if ( operationName == null ) <
< throw new AxisFault(JavaUtils.getMessage("noOperation"));

--- > > 415c718,719 < How can we monitor the performance of AXIS? --- > AXIS does not yet include specific Performance Monitoring Plugs. > 450a756,757 > AXIS does not yet include an Encoding Plug. > > >

> WSDL Parser and Code Generator Framework

> WSDL2Java is AXIS's tool to generate Java artifacts from WSDL. This > tool is extensible. If users of AXIS wish to extend AXIS, then they > may also need to extend or change the generated artifacts. For example, > if AXIS is inserted into some product which has an existing deployment > model that's different than AXIS's deployment model, then that product's > version of WSDL2Java will be required to generate deployment descriptors > other than AXIS's deploy.wsdd. >

What follows immediately is a description of the framework. If > you would rather dive down into the dirt of examples, > you could learn a good deal just from them. Then you could come back > up here and learn the gory details. >

There are three parts to WSDL2Java: >

> The symbol table
> The parser front end with a generator framework
> The code generator back end (WSDL2Java itself)

> >

> Symbol Table

> The symbol table, found in org.apache.axis.wsdl.symbolTable, will contain > all the symbols from a WSDL document, both the symbols from the WSDL constructs > themselves (portType, binding, etc), and also the XML schema types that > the WSDL refers to. >

NOTE: Needs lots of description here. >

The symbol table is not extensible, but you can add fields to > it by using the Dynamic Variables construct: >

> You must have some constant object for a dynamic variable key. For > example: public static final String MY_KEY = "my key";
> You set the value of the variable in your GeneratorFactory.generatorPass: > entry.setDynamicVar(MY_KEY, myValue);
> You get the value of the variable in your generators: Object myValue > = entry.getDynamicVar(MY_KEY);

> >

> Parser Front End and Generator Framework

> The parser front end and generator framework is located in org.apache.axis.wsdl.gen. > The parser front end consists of two files: >

> Parser

public class Parser {

public Parser();

public boolean isDebug();

public void setDebug(boolean);

public boolean isImports();

public void setImports(boolean);

public boolean isVerbose();

public void setVerbose(boolean);

public long getTimeout();

public void setTimeout(long);

public java.lang.String getUsername();

public void setUsername(java.lang.String);

public java.lang.String getPassword();

public void setPassword(java.lang.String);

public GeneratorFactory getFactory();

public void setFactory(GeneratorFactory);

public org.apache.axis.wsdl.symbolTable.SymbolTable > getSymbolTable();

public javax.wsdl.Definition getCurrentDefinition();

public java.lang.String getWSDLURI();

public void run(String wsdl) throws java.lang.Exception;

public void run(String context, org.w3c.dom.Document > wsdlDoc) throws java.io.IOException, javax.wsdl.WSDLException;

}

The basic behavior of this class is simple: you instantiate a > Parser, then you run it. >

Parser parser = new Parser();

parser.run("myfile.wsdl");

There are various options on the parser that have accessor methods: >

> debug - default is false - dump the symbol table after the WSDL file has > been parsed
> imports - default is true - should imported files be visited?
> verbose - default is false - list each file as it is being parsed
> timeout - default is 45 - the number of seconds to wait before halting > the parse
> username - no default - needed for protected URI's
> password - no default - needed for protected URI's

Other miscellaneous methods on the parser: >

> get/setFactory - get or set the GeneratorFactory on this parser - see below > for details. The default generator factory is NoopFactory, which > generates nothing.
> getSymbolTable - once a run method is called, the symbol table will be > populated and can get queried.
> getCurrentDefinition - once a run method is called, the parser will contain > a Definition object which represents the given wsdl file. Definition > is a WSDL4J object.
> getWSDLURI - once the run method which takes a string is called, the parser > will contain the string representing the location of the WSDL file. > Note that the other run method - run(String context, Document wsdlDoc) > - does not provide a location for the wsdl file. If this run method > is used, getWSDLURI will be null.
> There are two run methods. The first, as shown above, takes a URI > string which represents the location of the WSDL file. If you've > already parsed the WSDL file into an XML Document, then you can use the > second run method, which takes a context and the WSDL Document.

An extension of this class would ... >

> NOTE: continue this sentiment... >
>

> WSDL2

WSDL2

public class WSDL2 { >
    protected WSDL2(); >
    protected Parser createParser(); >
    protected Parser getParser(); >
    protected void addOptions(org.apache.axis.utils.CLOptionDescriptor[]); >
    protected void parseOption(org.apache.axis.utils.CLOption); >
    protected void validateOptions(); >
    protected void printUsage(); >
    protected void run(String[]); >
    public static void main(String[]); >
} >

Like all good command line tools, it has a main method. Unlike > some command line tools, however, its methods are not static. Static > methods are not extensible. WSDL2's main method constructs an instance > of itself and calls methods on that instance rather than calling static > methods. These methods follow a behavior pattern. The main > method is very simple: >
>

public static void main(String[] args) {

WSDL2 wsdl2 = new WSDL2();

wsdl2.run(args);

}

The constructor calls createParser to construct a Parser or an extension > of Parser. >

run calls: >

> parseOption to parse each command line option and call the appropriate > Parser accessor. For example, when this method parses --verbose, > it calls parser.setVerbose(true)
> validateOptions to make sure all the option values are consistent
> printUsage if the usage of the tool is in error
> parser.run(args);

If an extension has additional options, then it is expected to call > addOptions before calling run. So extensions will call, as necessary, > getParser, addOptions, run. Extensions will override, as necessary, > createParser, parseOption, validateOptions, printUsage. >
>

The generator framework consists of 2 files: >

> Generator

public interface Generator >
{ >
public void generate() throws java.io.IOException; >
} >
>

> GeneratorFactory

public interface GeneratorFactory >
{ >
    public void generatorPass(javax.wsdl.Definition, > SymbolTable); >
    public Generator getGenerator(javax.wsdl.Message, > SymbolTable); >
    public Generator getGenerator(javax.wsdl.PortType, > SymbolTable); >
    public Generator getGenerator(javax.wsdl.Binding, > SymbolTable); >
    public Generator getGenerator(javax.wsdl.Service, > SymbolTable); >
    public Generator getGenerator(TypeEntry, SymbolTable); >
    public Generator getGenerator(javax.wsdl.Definition, > SymbolTable); >
    public void setBaseTypeMapping(BaseTypeMapping); >
    public BaseTypeMapping getBaseTypeMapping(); >
} >

The GeneratorFactory interface defines a set of methods that the parser > uses to get generators. There should be a generator for each of the > WSDL constructs (message, portType, etc - note that these depend on the > WSDL4J classes: javax.xml.Message, javax.xml.PortType, etc); a generator > for schema types; and a generator for the WSDL Definition itself. > This last generator is used to generate anything that doesn't fit into > the previous categories >

In addition to the getGeneratorMethods, the GeneratorFactory defines > a generatorPass method which provides the factory implementation a chance > to walk through the symbol table to do any preprocessing before the actual > generation begins. >

Accessors for the base type mapping are also defined. These are > used to translate QNames to base types in the given target mapping. >

> >

> Code Generator Back End

> The meat of the WSDL2Java back end generators is in org.apache.axis.wsdl.toJava. > Emitter extends Parser. org.apache.axis.wsdl.WSDL2Java extends WSDL2. > JavaGeneratorFactory implements GeneratorFactory. And the various > JavaXXXWriter classes implement the Generator interface. >

NOTE: Need lots more description here... >

> WSDL Framework Extension Examples

> Everything above sounds rather complex. It is, but that doesn't mean > your extension has to be. >

> Example 1 - Simple extension of WSDL2Java - additional artifact

> The simplest extension of the framework is one which generates everything > that WSDL2Java already generates, plus something new. Example 1 is > such an extension. It's extra artifact is a file for each service > that lists that service's ports. I don't know why you'd want to do > this, but it makes for a good, simple example. See samples/integrationGuide/example1 > for the complete implementation of this example. >
>

> First you must create your writer that writes the new artifact. This > new class extends org.apache.axis.wsdl.toJava.JavaWriter. JavaWriter > dictates behavior to its extensions; it calls writeFileHeader and writeFileBody. > Since we don't care about a file header for this example, writeFileHeader > is a no-op method. writeFileBody does the real work of this writer.

public class MyListPortsWriter extends JavaWriter { >
    private Service service; >
    public MyListPortsWriter( >
            > Emitter emitter, >
            > ServiceEntry sEntry, >
            > SymbolTable symbolTable) { >
        super(emitter, >
                > new QName( >
                    > sEntry.getQName().getNamespaceURI(), >
                    > sEntry.getQName().getLocalPart() + "Lst"), >
                > "", "lst", "Generating service port list file", "service list"); >
        this.service = sEntry.getService(); >
    } >
    protected void writeFileHeader() throws IOException > { >
    } >
    protected void writeFileBody() throws IOException > { >
        Map portMap = service.getPorts(); >
        Iterator portIterator > = portMap.values().iterator(); >

        while (portIterator.hasNext()) > { >
            > Port p = (Port) portIterator.next(); >
            > pw.println(p.getName()); >
        } >
        pw.close(); >
    } >
} >
>

> Then you need a main program. This main program extends WSDL2Java > so that it gets all the functionality of that tool. The main of this > tool does 3 things:

> instantiates itself
> adds MyListPortsWriter to the list of generators for a WSDL service
> calls the run method.

public class MyWSDL2Java extends WSDL2Java { >

public static void main(String args[]) { >
MyWSDL2Java myWSDL2Java > = new MyWSDL2Java(); >

        JavaGeneratorFactory > factory = >
                > (JavaGeneratorFactory) myWSDL2Java.getParser().getFactory(); >
        factory.addGenerator(Service.class, > MyListPortsWriter.class); >

myWSDL2Java.run(args); >
} >
}

> >

> Example 2 - Not quite as simple an extension of WSDL2Java - change an artifact

> In this example, we'll replace deploy.wsdd with mydeploy.useless. > For brevity, mydeploy.useless is rather useless. Making it useful > is an exercise left to the reader. See samples/integrationGuide/example2 > for the complete implementation of this example. >

> First, here is the writer for the mydeploy.useless. This new class > extends org.apache.axis.wsdl.toJava.JavaWriter. JavaWriter dictates > behavior to its extensions; it calls writeFileHeader and writeFileBody. > Since we don't care about a file header for this example, writeFileHeader > is a no-op method. writeFileBody does the real work of this writer. > It simply writes a bit of a song, depending on user input.

Note that we've also overridden the generate method. The parser > always calls generate, but since this is a server-side artifact, we don't > want to generate it unless we are generating server-side artifacts (in > other words, in terms of the command line options, we've specified the > --serverSide option). >

public class MyDeployWriter extends JavaWriter { >
    public MyDeployWriter(Emitter emitter, Definition > definition, >
            > SymbolTable symbolTable) { >
        super(emitter, >
                > new QName(definition.getTargetNamespace(), "deploy"), >
                > "", "useless", "Generating deploy.useless", "deploy"); >
    } >
    public void generate() throws IOException { >
        if (emitter.isServerSide()) > { >
            > super.generate(); >
        } >
    } >
    protected void writeFileHeader() throws IOException > { >
    } >
    protected void writeFileBody() throws IOException > { >
        MyEmitter myEmitter > = (MyEmitter) emitter; >
        if (myEmitter.getSong() > == MyEmitter.RUM) { >
            > pw.println("Yo! Ho! Ho! And a bottle of rum."); >
        } >
        else if (myEmitter.getSong() > == MyEmitter.WORK) { >
            > pw.println("Hi ho! Hi ho! It's off to work we go."); >
        } >
        else { >
            > pw.println("Feelings... Nothing more than feelings..."); >
        } >
        pw.close(); >
    } >
} >
>

> Since we're changing what WSDL2Java generates, rather than simply adding > to it like the previous example did, calling addGenerator isn't good enough. > In order to change what WSDL2Java generates, you have to create a generator > factory and provide your own generators. Since we want to keep most > of WSDL2Java's artifacts, we can simply extend WSDL2Java's factory - JavaGeneratorFactory > - and override the addDefinitionGenerators method.

public class MyGeneratorFactory extends JavaGeneratorFactory > { >
    protected void addDefinitionGenerators() { >
        addGenerator(Definition.class, > JavaDefinitionWriter.class); // WSDL2Java's JavaDefinitionWriter >
        addGenerator(Definition.class, > MyDeployWriter.class); // our DeployWriter >
        addGenerator(Definition.class, > JavaUndeployWriter.class); // WSDL2Java's JavaUndeployWriter >
    } >
} >
>

> Now we must write the API's to our tool. Since we've added an option > - song - we need both the programmatic API - an extension of Parser (actually > Emitter in this case since we're extending WSDL2Java and Emitter is WSDL2Java's > parser extension) - and the command line API.

Here is our programmatic API. It adds song accessors to Emitter. > It also, in the constructor, lets the factory know about the emitter and > the emitter know about the factory. >

public class MyEmitter extends Emitter { >
    public static final int RUM = 0; >
    public static final int WORK = 1; >
    private int song = -1; >

    public MyEmitter() { >
        MyGeneratorFactory factory > = new MyGeneratorFactory(); >
        setFactory(factory); >
        factory.setEmitter(this); >
    } >
    public int getSong() { >
        return song; >
    } >
    public void setSong(int song) { >
        this.song = song; >
    } >
} >

And here is our command line API. It's a bit more complex that > our previous example's main program, but it does 2 extra things: >

> accept a new command line option: --song rum|work (this is the biggest > chunk of the new work).
> create a new subclass of Parser

public class WSDL2Useless extends WSDL2Java { >
    protected static final int SONG_OPT = 'g'; >
    protected static final CLOptionDescriptor[] > options = new CLOptionDescriptor[]{ >
       new CLOptionDescriptor("song", >
                > CLOptionDescriptor.ARGUMENT_REQUIRED, >
                > SONG_OPT, >
                > "Choose a song for deploy.useless: work or rum") >
    }; >

    public WSDL2Useless() { >
        addOptions(options); >
    } >
    protected Parser createParser() { >
        return new MyEmitter(); >
    } >
    protected void parseOption(CLOption option) > { >
        if (option.getId() == > SONG_OPT) { >
            > String arg = option.getArgument(); >
            > if (arg.equals("rum")) { >
                > ((MyEmitter) parser).setSong(MyEmitter.RUM); >
            > } >
            > else if (arg.equals("work")) { >
                > ((MyEmitter) parser).setSong(MyEmitter.WORK); >
            > } >
        } >
        else { >
            > super.parseOption(option); >
        } >
    } >
    public static void main(String args[]) { >
        WSDL2Useless useless > = new WSDL2Useless(); >

useless.run(args); >
} >
} >

Let's go through this one method at a time. >

> constructor - this constructor adds the new option --song rum|work. > (the abbreviated version of this option is "-g", rather an odd abbreviation, > but "-s" is the abbreviation for --serverSide and "-S" is the abbreviation > for --skeletonDeploy. Bummer. I just picked some other letter.
> createParser - we've got to provide a means by which the parent class can > get our Parser extension.
> parseOption - this method processes our new option. If the given > option isn't ours, just let super.parseOption do its work.
> main - this main is actually simpler than the first example's main. > The first main had to add our generator to the list of generators. > In this example, the factory already did that, so all that this main must > do is instantiate itself and run itself.