Question

I’m working on a web service using the top-down approach, generating service types and interfaces from a WSDL using JAX-WS’ wsimport. This provides a port type interface as follows, which I implement.

/**
 * This class was generated by the JAX-WS RI.
 * JAX-WS RI 2.2.4-b01
 * Generated source version: 2.2
 */
@WebService(name = "ExamplePortType", targetNamespace = "http://example.com")
public interface ExamplePortType {

    /**
     * @param example
     * @return java.lang.String
     * @throws ExampleException
     */
    @WebMethod
    @WebResult(name = "exampleResponse", targetNamespace = "http://example.com")
    @RequestWrapper(localName = "sendExample", targetNamespace = "http://example.com", className = "com.example.SendExample")
    @ResponseWrapper(localName = "sendExampleResponse", targetNamespace = "http://example.com", className = "com.example.SendExampleResponse")
    public String sendExample(
        @WebParam(name = "example", targetNamespace = "http://example.com")
        ExampleRequest example)
        throws ExampleException
    ;
}

It seems like the normal way to add this service to your application server (in my case, Tomcat), is to add the implementation class to the web.xml as a servlet and add WSServletContextListener as a listener. Very roughly, it seems that on initialization of the context, the listener constructs ServletAdapters which wrap the implementation bean and add them to a WSServletDelegate which is called by a thin WSServlet. Requests to your implementation are then handled by the WSServlet and passed to your bean by the delegate based on whatever URL patterns you have set up.

Is there a way to do the above programmatically? I want a method which accepts an instance of the above interface and returns to me an instance of a Servlet, which, if registered in a ServletContext, would route the appropriate requests to the wrapped implementation. Something like:

Servlet exampleServlet = new ServletAdapter().wrap(new ExamplePortTypeImpl());

One requirement is that I cannot rely on static configuration files (such as web.xml or sun-jaxws.xml). Does JAX-WS or a related library (ie: Axis2, etc.) provide this kind of functionality?

Apologies if something is not clear; it’s my first time here :). Any pointers are appreciated.

Currently Using JAX-WS 2.1, Tomcat 7, Servlet 3.0.

Answer 1

Okay, after a lot of experimenting, I’ve been able to put together something that works. I’ll post it here for the sake of documentation.

Basically, I got to this by emulating or re-implementing how JAX-WS creates it’s WSServlet from it’s WSServletContextListener. Unfortunately, I was not able to find an easier or better support and straightforward way of doing this.

Basically, my factory creates a WSEndpoint using it’s WSEndpoint.create() method. create() takes as input the Class of the WebService implementation which I’m trying to wrap. Most of the other inputs are null to encourage WSEndpoint to use a default or try to pull some configuration off of annotations in the implementation class.

I then use a new ServletAdapterList() to create a ServletAdapter using the previously created WSEndpoint. For this, since I’m creating one Servlet per implementation class, the name of the adapter doesn’t matter, and it can be configured to send all traffic to the implementation regardless of the URL.

Then, I create a single new WSServletDelegate() using a singleton list of the prior ServletAdapter. The only trick here is that it seems that JAX-WS has, at least for this and the next step, a bad habit of storing some values in the init params of the ServletContext. It also doesn’t null check properly, even though it has defaults to use if the parameters are not in the context. So I also ended up creating a dummy implementation of the ServletContext which I pass into the WSServletDelegate constructor to make it feel like it’s looking up init params.

Lastly, I created an implementation of HttpServlet that forwards requests to the WSServletDelegate similar to how WSServlet does. Since WSServlet again stores the delegate object in the ServletContext init params, I found it easier to just re-implement its functionality than mess around with the existing WSServlet. This implementation of an HttpServlet can then be treated like any normal Servlet that will accept and handle SOAP webservice calls.