I’ve noticed an issue in WSDLs generated by .NET 2.0 apps: some of the element(s) and their corresponding complextype definitions have same name. If you happen to generate JAX-WS portable artifacts (see below) from one such WSDL for your project (during technology migration etc. and you don’t want the consumers who use this WSDL to be affected) using conversion tools like Apache CXF (wsdl2java ), Apache Axis (WSDL2Java), JAX-WS (wsimport) etc., you’ll most likely get this error:
A class/interface with the same name “XXXX” is already in use. Use a class customization to resolve this conflict.
Use an option/argument -autoNameResolution that automatically resolves naming conflicts in WSDL without requiring the use of binding customizations.
2) wsimport (a JAX-WS tool)
Use an option -B-XautoNameResolution (without spaces)
It’s a bit tricky here, the WSDL needs to be modified a little bit.
We can seperate out element(s) and the corresponding complextype definitions in different namespaces. This way the two Java classes with same name (one for element, another for complex type) will get generated in different packages and hence there wouldn’t be any problem in generating service code. There can be other tweaks too which would serve the same purpose, but I think the aforementioned one is cleaner, as we need not have to change the names of element/complex type definition.
JAX-WS portable artifacts
- Service Endpoint Interface (SEI)
- Exception class mapped from wsdl:fault (if any)
- Async Reponse Bean derived from response wsdl:message (if any)
- JAXB generated value types (mapped java classes from schema types)
- Apache CXF: Implementing Failover and Load Balancing (singztechmusings.wordpress.com)
- Apache CXF: How to add custom SOAP headers to the web service request? (singztechmusings.wordpress.com)
- Apache CXF-based Web Services: How to log/print the payload XML of incoming SOAP request using InInterceptor? (singztechmusings.wordpress.com)