JAX-WS version

JAX-WS 2.2 is the latest version, and it’s supported by WebSphere 8.5. However, it appears to sort-of want Java 7.

It can be used with Java 6 via the Java Endorsed Standards Override Mechanism. I played with this a little and got the wsimport to work, but my Java 6 RAD/WebSphere were not working yet. I have asked what the “correct” way is to do this for the runtime environments, but in the meantime using JAX-WS 2.1 looks cleaner under Java 6.


wsimport can either be run as a script or from Ant.

The script is part of the SDK now, even included with J2SE. The one included with WebSphere is documented in the InfoCenter.


The Ant task is actually provided by Sun classes, but they are included in WebSphere’s jars as well. The Wsimport Ant task is documented here.

Jar files

The jars required to run the Ant task are found in the WebSphere/AppServer/plugins directory. These two seem to be all that is required:

  • com.ibm.jaxws.tools.jar
  • com.ibm.jaxb.tools.jar

If you want to try JAX-WS 2.2. under Java 6, you also need from the WebSphere/AppServer/endorsed_apis directory:

  • jaxb-api.jar
  • jaxws-api.jar


Create an Ant taskdef like this:

    <path id="jaxws.gen.classpath">  
        <fileset dir="${websphere.plugins.dir}">  
            <include name="com.ibm.jaxws.tools.jar" />  
            <include name="com.ibm.jaxb.tools.jar" />  

    <!-- Ant task definition for wsimport -->  
    <taskdef classpathref="jaxws.gen.classpath" name="wsimport" classname="com.sun.tools.ws.ant.WsImport"/></span>

wsimport task

A sample task looks like this:

        <wsimport sourcedestdir="${gen.src}" target="2.1"  
                  debug="true" verbose="true"  
  • sourcedestdir says to keep the generated source .java files and to put them in the specified directory. I prefer a separate source directory to distinguish it from edited code.
  • target is the JAX-WS version. (It seems to default to 2.2, even with my WAS 8.5.5 Java 6 SDK.)
  • wsdl points to the local file to generate the proxy from
  • wsdllocation allows the generated code to access the necessary WSDL from a location other than where the source WSDL file was located. See Bare JAX-WS, below, for some details. I admit I’ve yet to work out my preferred solution here. I want to reference it from a location like /WEB-INF/wsdl/service.wsdl, but that might still require changes to the generated source to accomplish.
  • xnocompile means to not compile the source code immediately. Since either RAD or a later Ant step will do this, it’s unnecessary. No compiling also means the destdir isn’t actually used.
  • xendorsed="true" , not shown here, is necessary if you want to generate JAX-WS 2.2 code from Java 6

References and Articles

Edit: Update for newer WebSphere fixpacks

A colleague discovered that with the latest copies of the two “plugins” jars, the wsimport task no longer works. Sure enough, com.sun.tools.ws.ant.WsImport is no longer in com.ibm.jaxws.tools.jar. The Knowledge Center article Generating Java artifacts for JAX-WS applications from a WSDL file still claims that is the correct class for the Ant task, but we were unable to find it in any of the jars that seem to be included by the ws_ant script that the article says must be used.

Instead, however, the class com.ibm.jtc.jax.tools.ws.ant.WsImport is in com.ibm.jaxws.tools.jar, and it appears to work as a drop-in replacement:

  <taskdef classpathref="jaxws.gen.classpath" name="wsimport" classname="com.ibm.jtc.jax.tools.ws.ant.WsImport"/>