David,
Read my post on 3-16 titled "Can Wsdl2Java make the stub implement a specified interface?", it's related.
I think the appropriate way to do this is to generate a java interface file which matches the generated class, and is implemented by it. These could then be copied and used in client or test code, without having to make a concrete dependency on either the stub or the original class. The generated interface name could be the original class name with an I prepended (even though I don't like that convention), or made configurable.
I think this is a valid requirement, because I often auto-generate java stubs for use in my test code, but use the original beans in that same test code, thus encountering the namespace conflicts you describe (same class, different packages). Also, if you have client code which depends on the stubs, it is cleaner and more testable to be able to make it depend on an interface rather than a concrete class.
FYI, I also have automated code in my build script (Maven) which can automatically build a war from the current project, deploy it, and invoke Wsdl2Java (with a couple of hacks) to automatically generate the stubs. You can also run it against an external war or deployed war. This is really nice if you want to use the stubs during testing, or automatically keep the stubs up-to-date with the wsdl.
I'd dig in and try to do this if I had more time or perhaps if an axis dev showed interest in this.
Thanks, Chad Woolley **
