When Web service development, Wsdl2java client code generation __web

When using a Web service, if you are invoking a Web service of your own development, you can have a method interface or a Parameter object entity class or something, but if you are calling a Third-party service, in addition to the WSDL document for the Web service address, Without any material coding, writing native calls is too troublesome, and then you need to write a method of the interface class yourself.

This, there is already a relatively mature tool, can be automatically generated, the following simple introduction.

Apache's Wsdl2java tool, now looks like CXF and Axis have a set of different uses, but the generated code will be different, it is said that the CXF provided Wsdl2java tools.

Wsdl2java usage:

Wsdl2java-p com-d Src-all aa.wsdl

-p Specifies the namespace of its WSDL, which is the package name to generate code for:

-d Specifies the directory where the code is to be generated

-client code to generate client test Web service

-server the code for the build server to start the Web service

-impl to generate Web service implementation code

-ant Generate Build.xml files

-all generates all start endpoint codes: Types,service Proxy,,service interface, server mainline, client mainline, implementation object, and an T build.xml file.

See Detailed usage: http://cwiki.apache.org/CXF20DOC/wsdl-to-java.html

The first use of this set of CXF tools, found not very convenient, after all, rely on CXF provided by the tool jar package, the individual is not very like to use.

Later found that the JDK also brought the Web service to generate Java code features, looks like the 1.6 version began, after the trial found that the effect is very good, decisively into its embrace. Here is a simple introduction, in case you forget.

Open the Bin directory under the JDK and see if you can find the "wsimport.exe" file.

In general, there will be

If not, your JDK does not support this feature.

Then enter the Wsimport in the DOS window and hit the carriage.

If prompted incorrectly, your JDK environment variables are not well matched.

In a word, if you enter Wsimport under DOS window normal, you can

If OK enter the following command to generate the WSDL file Java file

Wsimport http://127.0.0.1/TicketMobile/services/Cococ?wsdl-keep-p com.llg.ws2-s G:/ws

Parameter description

Wsimport this is a must. The name of the tool

http://127.0.0.1/TicketMobile/services/Cococ?wsdl WSDL file

-keep whether to generate a source file

-P COM.LLG.WS2 Java package name after generation

-S G:/ws which directory to put after generation

But a few days ago, when a third party provided Web service using the tool to generate Java code, there was a mistake, online search finally found the reason.

When you use CXF Wsdl2java or javax wsimport tools, you may encounter problems with the generated response class file name conflicts

The console code Wsdltojava error:thrown by Jaxb:a Class/interface with the same name "* * *" is already in use. Use a class customization to resolve this conflict.

Currently available options:

Apache Wsdl2java tools, using-autonameresolution automatic Processing

Wsdl2java-autonameresolution http://hello.joy2everyone.com/yourWebService?wsdl

JDK self-brought tools

Wsimport-p Com.test.client-keep http://hello.joy2everyone.com/yourWebService?wsdl-B-XautoNameResolution

2. If the Web service is developed by your own, you can modify the code and use custom bindings to see the Sun WebService documentation in detail

For example:

Java code public Interface Validateccservice @WebMethod @WebResult (name = "Response") public validateccre Sponse VALIDATECC (@WebParam (name = "Request") Validateccrequest request);

The name of the method defined in this case, if you use a tool to generate client code, there is likely to be a response conflict, because there is a message about the interface method in the defined WSDL

<wsdl:message name= "Validateccresponse" >

</wsdl:message>

The message defined by the method name and the Validateccresponse returned by the interface definition produce a naming conflict when the tool generates client code.

However, by changing the interface method name:

Java code public Interface Validateccservice @WebMethod @WebResult (name = "Response") public validateccre Sponse Validate (@WebParam (name = "Request") Validateccrequest request);

Can resolve the conflict,