axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Butek" <bu...@us.ibm.com>
Subject Re: More big emitter work - adding a symbol table
Date Wed, 21 Nov 2001 16:58:16 GMT
I've implemented the symbol table in axis.  All the tests pass.  That was
my primary goal.  However, I consciously left out some things just to
accomplish my primary goal in a timely manner.  Here's some work that's
still needed.

- I got rid of WsdlAttributes and moved most of its code elsewhere.  One
bit that did not get moved was the isInSoapBinding method.  This may be
replaced by the isReferenced logic on SymTabEntry.  None of our tests
depend on this, so I left it out for the moment.

- SymbolTable.partStrings (was Emitter.partStrings) doesn't have any
literal code.  This belongs somewhere in the Writers but I don't know
where.  Since our tests didn't depend on it, I left it out for the moment.
Tom, you're rewriting the literal stuff, right?  Should I hold off putting
this back in?

- JavaStubWriter.writeOperation has the code snippet:

            if (type == null) {
                // XXX yikes, something is wrong
            }

We have to revisit this.  It's possible that type IS null.  What do we do
then?

- If a reference to a type is encountered before the definition, a RefdType
is created and added to the symbol table.  Once the type is defined, this
RefdType is replaced by a real type.  Other objects may have referred to
the RefdType.  Their references also need to be replaced.  This doesn't
affect any of our existing tests.

Russell Butek
butek@us.ibm.com


Russell Butek/Austin/IBM@IBMUS on 11/20/2001 01:20:49 PM

Please respond to axis-dev@xml.apache.org

To:   axis-dev@xml.apache.org
cc:
Subject:  More big emitter work - adding a symbol table



We've run across a problem with the emitter where we can still have name
clashes.  In order to properly clean it up, yet still have references to
the original QNames of objects, we really need a symbol table.  Most
compilers/emitters have symbol tables, so it's a wonder we haven't had one
up to now.  A symbol table will buy us a few things:
1.  Fix this immediate problem
2.  Have a clean lookup of objects by QName
3.  Better organize the extra stuff we've added that WSDL4J doesn't have
(WsdlAttributes, Parameters, TypeFactory, Type)
4.  Take one more step closer to a reusable Wsdl2XXX framework

We already have a larval symbol table in TypeFactory, but it ONLY contains
XML types, no WSDL types.  This has to grow up.  I've added a symbol table
in my sandbox (I thought this would be easy.  HA!  I unraveled a whole nest
of vipers.).  I am testing it right now.  If my tests are done by COB
tomorrow, I will commit the changes.  Otherwise these changes will probably
wait until after alpha3.

If you care about the details, read on.

1.  Create a SymTabEntry (SYMbol TABle Entry) abstract base class:

public abstract class SymTabEntry {
    // QName of the object
    public getQName();

    // Munged name (ie, Java name in Wsdl2java)
    private String name;
    public String getName();
    public void setName(String name);

    // Is this object referred to by another object?
    public isReferenced();

    // HashMap of any information that a Writer extension may find
necessary.
    // For example, this is where the method signature string could go for
the PortType
    private HashMap dynamicVars;
    public Object getDynamicVar(Object key);
    public void setDynamicVar(Object key, Object value);
}

2.  Create a number of SymTabEntry subclasses:  TypeEntry (this is what
today's Type class evolves to), MessageEntry, PortTypeEntry, BindingEntry,
ServiceEntry.  In addition to the SymTabEntry stuff, these may only add a
pointer to their specific WSDL/XML types.  But there will be other info,
anything we feel is lacking in the WSDL4J object; for example,
PortTypeEntry will contain a list of Parameters objects (which is now the
operationParameters HashMap).

3.  WsdlAttributes will go away and its pieces will go into SymTabEntries:
BindingAttr, OperationAttr into BindingEntry, PortTypeAttr into
PortTypeEntry; and the scanBindings method will go into
JavaWriterFactory.writerPass (see #5 below).

4.  A new class - SymbolTable - will embody the idea of a symbol table:  a
HashMap of symbols and the population of that HashMap.

5.  Emitter will now contain a SymbolTable.  This symbolTable will contain
entries of the form <key, value> where key is of type QName and value is of
type Vector.  The Vector's elements are all of the objects that have the
given QName.  This is necessary since names aren't unique among the WSDL
types.  message, portType, binding, service, could all have the same QName
and are differentiated merely by type.  SymbolTable will contain
type-specific getters to bypass the Vector layer:  public PortTypeEntry
getPortTypeEntry(QName name), etc.

6.  WriterFactory will now look like:

public interface WriterFactory {
    public void writerPass(Definition def, SymbolTable symbolTable); // NEW
METHOD:  allow the Writer extension to make a pass through the symbol table
doing any pre-writing logic, like creating the Java names for each object
and constructing signature strings.
    public Writer getWriter(MessageEntry message, SymbolTable symbolTable);
// NEW METHOD:  Note that this writer will be a no-op in Wsdl2java, but
since we have a writer for each top-level object, we really need to provide
a message writer.
    public Writer getWriter(PortTypeEntry portType, SymbolTable
symbolTable);
    public Writer getWriter(BindingEntry binding, SymbolTable symbolTable);
    public Writer getWriter(ServiceEntry service, SymbolTable symbolTable);
    public Writer getWriter(TypeEntry type, SymbolTable symbolTable);
    public Writer getWriter(Definition definition, SymbolTable
symbolTable); // Note that there is no DefinitionEntry because Definition
may not have a name and is only needed in this method.  I think.
    public void setEmitter(Emitter emitter); // I hope we can eventually
get rid of this method, but until then...
}

7.  Since the symbol table moves outside of TypeFactory, all of the code in
TypeFactory will move and the class will be deleted.

8.  The writers will all have to change to accommodate this new design.

Russell Butek
butek@us.ibm.com




Mime
View raw message