You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by bu...@apache.org on 2003/01/03 15:47:33 UTC

DO NOT REPLY [Bug 15779] New: - WSDL2Java generates uncompilable code when generated package name matches class name

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15779>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15779

WSDL2Java generates uncompilable code when generated package name matches class name

           Summary: WSDL2Java generates uncompilable code when generated
                    package name matches class name
           Product: Axis
           Version: 1.1beta
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: WSDL processing
        AssignedTo: axis-dev@xml.apache.org
        ReportedBy: gdaniels@macromedia.com


WSDL2Java generates package names based on the namespaces in the WSDL document.
So if the target namespace is "urn:Foo", we'll generate a package "Foo".

Now imagine a service called "Foo" in namespace "urn:Foo".  We'll end up with 
something like this:

+ Foo (package)
  |
  = Foo (class)
  = FooService (class)
  ..etc

When generating code, we always use fully-qualified classnames so as to avoid 
potential collisions with other system- or user-defined code.  So, there'll be 
some code like this in FooService:

    public Foo.Foo getFoo() ...

Therein lies the problem.  Since we're in the package Foo already, the 
compiler doesn't know whether "Foo." means the *class* Foo or the *package* 
Foo, and procedes to toss its cookies.

Proposed solution : I'm not too familiar with the generation code, but 
assuming we at some point have a list of what we're going to generate before 
we actually do anything, we should check for collisions of package names and 
class names, and if we find one, mangle the package name by appending "_pkg", 
so we'd make "Foo_pkg" in the above case.

Thanks to James Black for stumbling across this one in the midst of tracking 
another.