axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Updated: (AXIS-1522) JavaGeneratorFactory should not perform collision protection for types that are in excluded namespaces
Date Fri, 20 Aug 2004 13:41:20 GMT
The following issue has been updated:

    Updater: Ian P. Springer (
       Date: Fri, 20 Aug 2004 6:39 AM
             Attachment changed to disable_collision_protection_for_excluded_namespaces.patch
For a full history of the issue, see:

View the issue:

Here is an overview of the issue:
        Key: AXIS-1522
    Summary: JavaGeneratorFactory should not perform collision protection for types that are
in excluded namespaces
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Axis
             WSDL processing
             current (nightly)

   Reporter: Ian P. Springer

    Created: Fri, 20 Aug 2004 6:38 AM
    Updated: Fri, 20 Aug 2004 6:39 AM
Environment: n/a

The Java emitter's collision protection feature is enabled by default, which is fine. However,
collision protection should never be performed for types that are in namespaces that the user
has indicated should be excluded. Here's a use case that demonstrates why:

WSDL w/ types target namespace nsRed imports three other WSDLs - nsOrange, nsYellow, and nsGreen.
nsOrange and nsYellow also import nsGreen. nsGreen defines an element named Destroy that has
an anonymous complex type. 

I first run wsdl2java on the imported WSDLs and jar up the generated types into a reusable
lib specTypes.jar. The class generated for nsGreen's Destroy type is named _DestroyType. I
then run wsdl2java on nsRed, specifying that nsOrange, nsYellow, and nsGreen should be excluded,
and including specTypes.jar in the classpath. wsdl2java encounters nsGreen's Destroy anon
type multiple times in its traversal of nsRed and its imported WSDLs. each time it encounters
it, although it doesn't actually generate any classes because of the namespace exclusion,
it keeps bumping up the classname that is stored in the SymbolTable for the anon Destroy type.
when all's done, the class that ends up in the symbol table is named _DestroyType5. this is
the class that ends up being written into the binding impls and stubs for the operations in
nsRed. unfortunately, no such class exists; the pregenerated class that is in specTypes.jar
is named _DestroyType, not _DestroyType5. So when I try to compile the nsRed generated classes,
I get compile errors for the impls and stubs. If collision protection is never performed for
types in excluded namespaces, this issue goes away. This makes sense - since there's no way
to know what the pregenerated classname is, the best assumption to make is that is does not
have a numerical suffix.


This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message