+

Search Tips   |   Advanced Search

Use a third-party JAX-WS web services engine

In certain situations we might need to set up a third-party JAX-WS web services engine. For example, we must set up a third-party JAX-WS web services engine to deploy applications that use a single run time across various application servers such as WebSphere Application Server, JBoss, and WebLogic, or to build JAX-WS web services applications using third party JAX-WS run time such as CXF, Axis2, and Metro.

Use of a third-party JAX-WS run time has limitations. It also requires mandatory configuration changes, and in some cases, it requires manual intervention to resolves issues that occur during deployment and when running the application. These limitations and issues vary based on the third-party JAX-WS run time we decide to use. We should understand the limitations for the third-party JAX-WS run time we are preparing to use before configuring the system to use that implementation.

The following limitations exist regardless of which third-party JAX-WS implementation we use:

Even though IBM supports the enablement of third party JAX-WS run times to run on WAS, and ensures the successful deployment of applications that use such run times, IBM does not provide support for resolving JAR file conflict problems, or any problem that a stack trace indicates is in the third party code.

When we deploy an application EAR file with a third-party JAX-WS implementation on WAS, the WAS run time must ensure the use of the third-party engine, and disable the use of the existing WAS JAX-WS web services engine.

WAS does not claim support for any of the third-party JAX-WS run times, but has tested the deployment and execution of applications that use such runtimes.

We must complete the following steps before we can use an external JAX-WS run time in an application.


Tasks

  1. Set the class loader policy to Classes loaded with local class loader first (parent last) at the module level.

    Change the class loader policy to parent last ensures that the external third-party JAX-WS run time and their dependent library JAR files are first in the class loader search path, thereby ensuring that the third-party implementation is used instead of the WAS.

    1. In the administrative console, click...

              Applications > Application Types > WebSphere enterprise applications > application_name> Manage modules>webmodule_name.

    2. Select Classes loaded with local class loader first (parent last) from the drop down list.

    3. Click OK, and then Save to save our changes.

    1. Click OK, and then Save to save our changes.

  2. Turn off web services annotation scanning.

    Annotation scanning can be turned off at the application level or at the server level.

    To turn off annotation scanning at the application level, set the DisableIBMJAXWSEngine property in the META-INF/MANIFEST.MF of a WAR file or EJB module to true. Example:

    Manifest-Version: 1.0
    DisableIBMJAXWSEngine: true 

    To turn off web services annotation scanning at the server level:

    1. In the administrative console, go to the Custom properties page for the Java virtual machine.

      (ZOS) Click Servers > Server Types > WebSphere application servers > server_name, and then, in the Server Infrastructure section, click Java and process management > Process definition > Control > Java virtual machine > Custom properties

      Servers > Server Types > WebSphere application servers > server_name, and then, under Server Infrastructure > Java and process management > Process definition > Java virtual machine > Custom properties

    2. Set the com.ibm.websphere.webservices.DisableIBMJAXWSEngine property to true

      If this property does not already exist for our configuration, click New, and add com.ibm.websphere.webservices.DisableIBMJAXWSEngine in the Name field and true in the Value field.


What to do next

  • Java virtual machine custom properties