Generating server-side bindings is normally only done when you're starting with WSDL and don't have a service. You already have a service, so you don't have to generate the server-side bindings. All you need is a deploy.wsdd file (which you COULD get by generating the server-side bindings, tweaking the generated deploy.wsdd file to fit your service and throw everything else away).
If you deploy your service, then use the WSDL from that service to generate client-side bindings, then your client will be able to talk to your service, even though the type names on the client are different than the type names on the server. All that matters is what goes across the wire. Russell Butek [EMAIL PROTECTED] [EMAIL PROTECTED] on 03/07/2002 04:32:11 PM Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: type name collision From: PAUL MAENNER I have an existing service that I've used with Apache SOAP 2.2 for some time. I was trying to get it to work with Axis (nightly build, 3-6-2002). I performed Java2WSDL on the existing class and then WSDL2Java on the resulting wsdl in order to generate the needed wsdd. (I ignore all files generated other than the wsdd) Unfortunately, the types specified by the wsdd do not exist in my actual package. I determined that this was caused by the naming convention I had used for return types from the service methods. Each return type is named <Methodname>Response where Methodname is the name of the service method. Axis uses the exact same naming convention for the messages defined in the wsdl. The name clash results in the wsdd mangling my type name to <Methondname>Response_Type rather than the correct type that actually exists in my package. The deployment fails since there is no such class. The failure is delayed until the first use, it doesn't fail at deploy time. It would be nice if the names of messages and the names of types were in different name spaces or if the message names used a different naming convention. I can't change the names of my types anymore because I want my service to work with existing Apache SOAP 2.2 clients that already use the service as deployed on a SOAP 2.2 server.
