Question

I’m using wsdl2java to generate service. Arguments for generation are following:

-p com.dummy.tst.service -u -f -sp -s -b -ssi -d xmlbeans -uri /some/path/service.wsdl -ss -g -sd -o /some/path/gen

After generation I’ve got a services.xml file with line like

<parameter name="ServiceClass">com.dummy.tst.service.TestSoapBindingImpl</parameter>

Then in gen directory I’ve got TestSoapBindingImpl.java with list of methods but every method is defined as follows

throw new  java.lang.UnsupportedOperationException("Please implement " + this.getClass().getName() + "#myMethod");

And also there’s a TestSoapBindingStub.java file which actually contains implemented methods. In axis-1 there was only one file with methods description and implementation and in axis-2 I’ve got 2 files.

What should I do with these files? Impl file, that is specified as default service methods container (in services.xml) contains only dummies, so I can’t use deployed service and replacing TestSoapBindingImpl with TestSoapBindingStub in services.xml also does not lead to the desired result.

Answer 1

TestSoapBindingStub.java is for the client. It contains code to call the web service on a remote system.

On the service side, every time a request comes in, Axis2 will create an object of the type specified in services.xml as the ServiceClass. It will then call the requested function within the ServiceClass object, using the object that was provided by the client.

Using the code generated by wsdl2java, every call to the service will create an object of type om.dummy.tst.service.TestSoapBindingImpl, which as you’ve noted will throw an exception for each call. There are two approaches to make a working service.

1. You can use the TestSoapBindingImpl.java file that you have as a starting point. Remove the throws line from each function and fill in each function body with the code that you actually want to execute when a request comes in.

2. Alternately, you can use services.xml as a starting point. Define a class of your own to be the service class. Replace the reference to com.dummy.tst.service.TestSoapBindingImpl with a reference to the name of your own service class. wsdl2java probably generated a file named something like TestSoapBindingSkeleton.java which defines the interface which the service class should implement. Your custom service class should implement this interface.

The projects that I’ve been working on use approach #2. We write our own service class which implements the skeleton interface. When packaging the service into an AAR file, you include the services.xml file in the AAR. Our packaging rule performs a text substitution on the generated services.xml to update the ServiceClass with the name of our service class.