Can Wsdl2Java make the stub implement a specified interface?

[Chad Woolley <li...@thewoolleyweb.com>]

Hi,

I would like Wsdl2Java to make the generated class implement an 
interface.  This would save a ton of effort and duplication during 
testing, where I currently have to duplicate a lot of stub-generation 
and test code for both classes.

Is there any support for this planned?  Has anyone else requested this 
(I didn't find anything in the archives)?   Would a patch to allow this 
be considered?

Thanks,
Chad

Re: axis stubs

[Chad Woolley <li...@thewoolleyweb.com>]

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
**