If not, how do I reconcile having 2 versions of source code on client-side for my JavaBeans?
I think you can define in your wsdl-file the target package name. If you are using java2WSDL to generate your WSDL -File you can use the -p option. Regards Ferruh -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Gesendet: Montag, 27. Juni 2005 20:23 An: axis-user@ws.apache.org Betreff: wsdl2java: what to do with client-side (re-)generated java bean classes I have a Swing application that is also a client of a web service I created. That Swing client uses several Java Bean classes, which are also used as arguments/return types in the said web service. When I use wsdl2java to generate client-side web service stubs, source code for these JavaBean data beans is also re-generated, so the client application ends up with 2 copies for each JavaBean: -one in hand-written application.beans package, and -one in wsdl2java-generated application.wsgenerated package. Since the Swing part of my client app makes use of the application.beans package, I'd like to be able to pass *those* JavaBeans as args to web service operations. Is that reasonable? However, generated javaBean sources have some axis-added static methods not present in original JavaBeans - such as getSerializer and getDeserializer. Does that mean that using hand-coded JavaBeans as args to webservice is not the right way to go, and I must use the generated source? If not, how do I reconcile having 2 versions of source code on client-side for my JavaBeans? thanks -nikita
