Paul, The package naming change should be to ensure you're not creating collisions in package naming generated because of similarities in namespace and existing code structures. The package name in itself should not matter as long as it's unique.
Allowing your customer to specify any number of differing interfaces for you to implement is obviously going to be a big challenge for you. I'd suggest turning it around and making it a small challenge for your customers: provide them with an interface/framework that they need to implement and/or call. I'm sure that you're customers might apreciate this (not knowing their expectations), as having a well defined task to execute is typically easier than a whole design job. Regarding WSDL2Java, write yourself a batch file you can easily modify the wsdl2java parameters in and learn through trial and error. Does this fit your situaton? Cheers Martin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 21, 2008 12:46 AM To: [email protected] Subject: RE: Generating generic stubs Hi Martin, Thanks for the reply, I will try the name space to package now, I was looking at this yesterday on the axis web pages. Do you examine the wsdl file first and replace any namespaces? The problem is that although we provide an api that expect other people use to provide an interface for use to call, we don't specify what their package structures should be. SO one provider could use the format (1) com.z.y.x and the other could use (2) com.c.b.a. Would this cause problems with invoking the service? Say I used the wsdl for (1) above to generate the stubs and override the package structure, but then I use the same stub classes to call service (2) which would have a different namespace to package structure. Thanks -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 20 May 2008 16:58 To: [email protected]; [EMAIL PROTECTED] Subject: RE: Generating generic stubs Hi Paul, I have used the XMLBeans binding with Axis2 to generate client stubs. I have a number of potential end-points too, and I instantiate one 'Service' object (from the generated code) for each one. I pass the Service object with the end-point I'm interested in to my framework/code doing the actual call on this stub. So far I have avoided touching the generated code at all so as to minimize the coupling. I package the generated code in one archive, and my framework in another to allow me to regenerate the stub as needed. I user Spring to hook up the necessary resources. As for package naming, use the -ns2p option in wsdl2java: -ns2p ns1=pkg1,ns2=pkg2 Specify a custom package name for each namespace specified in the wsdls schema. Hope this helps! Martin -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 20, 2008 7:42 AM To: [email protected] Subject: Generating generic stubs Hi, We have provided an api that people wishing to interface with our system must code to. This ensures that any users will provide the same objects and the same service name that we will call. What we would like to do is to create a set of generic stubs that we can use to make a call to any provider, by looking up the end point in the database for a particular system. So far I have in part achieved this by calling getService() and passing in an endpoint URL. When I look at the code generated with wsdl2java it is not completely generic though, I have overridden the package structure to look like 'stub.generic.ltc' but the namespaces in the generated classes still map to the packages defined by the provider (I guess this is due to the WSDL namespaces). Has anybody done this sort of thing before? Is it possible? Am I approaching this in the right way if it is possible? And should I be editing the generated code to remove any namespaces? Ideally the situation we would like to end up with is one set of stubs generated and placed into a jar file, with the endpoint switched at runtime to point to a particular provider, we would only ever use one wsdl to generate the stubs and all new providers that would like us to call this service would only need to provide us with an endpoint. Thanks, Paul Ockleford ********************************************************************** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ********************************************************************** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail ********************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
