[jira] Closed: (AXIS-1522) JavaGeneratorFactory should not perform collision protection for types that are in excluded namespaces

[ax...@ws.apache.org]

Message:

   The following issue has been closed.

   Resolver: Davanum Srinivas
       Date: Thu, 14 Oct 2004 4:47 PM

Applied Patch.

thanks,
dims
---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/AXIS-1522

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: Closed
   Priority: Major
 Resolution: FIXED

    Project: Axis
 Components: 
             WSDL processing
   Versions:
             current (nightly)

   Assignee: 
   Reporter: Ian P. Springer

    Created: Fri, 20 Aug 2004 6:38 AM
    Updated: Thu, 14 Oct 2004 4:47 PM
Environment: n/a

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

  


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira