Network Deployment (Distributed operating systems), v8.0 > Develop and deploying applications > Develop web services > Deploy web services

Use a third-party JAX-WS web services engine

In certain situations you might need to set up a third-party JAX-WS web services engine. For example, set up a third-party JAX-WS web services engine if deploy applications that use a single runtime across various application servers such as WAS, JBoss, and WebLogic, or to build JAX-WS web services applications using third party JAX-WS run-times such as CXF, Axis2, and Metro.

Use of a third-party JAX-WS runtime 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 you run the application. These limitations and issues vary based on the third-party JAX-WS runtime you decide to use. You should understand the limitations for the third-party JAX-WS runtime you are preparing to use before you configure the system to use that implementation.

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

• The WAS runtime restricts usage of application modules that use both the JAX-WS implementation provided with WAS, and an external JAX-WS implementation in the same application EAR file. We must use either the JAX-WS implementation provided with WAS or the external implementation in a single application EAR file. This limitation ensures that the runtime WAS does not conflict with the external third-party JAX-WS implementation.
• We must remove any conflicting JAR files from the application library before you deploy an application that uses an external JAX-WS implementation. Most of the external third-party JAX-WS runtimes include some JAR file libraries that are already installed on WAS. This situation causes conflicts in the application library.

• After an application that uses a third-party JAX-WS runtime is deployed on WAS, it is not recognized as a service client or provider. Therefore, you cannot attach application level policy sets to these applications. We must rely on external runtimes support quality of service. Following is a list of WAS features that are not available if you decide to deploy and run application that uses third-party JAX-WS implementations:
  • WS-Security, WS-RM, and WS-Transactions policy sets
  • WSDM
  • JNDI lookup to retrieve JAX-WS Service or Port Instance.

Even though IBM supports the enablement of third party JAX-WS runtimes to run on WAS, and ensures the successful deployment of applications that use such runtimes, 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 you deploy an application EAR file with a third-party JAX-WS implementation on WAS, the WAS runtime 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 runtimes, but has tested the deployment and execution of applications that use such runtimes.

We must complete the following steps before you can use an external JAX-WS runtime in an application.

Procedure

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 runtime 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 admin console, click Applications > Application Types > WebSphere enterprise applications > application_name > Class loading and update detection.

   2. Under Class reloading options, select Override class reloading settings for web and EJB modules .

   3. Under Class loader order, select Class loader order property to Classes loaded with local class loader first (parent last).

   1. Click OK, and then Save to save your 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 admin console, go to the Custom properties page for the Java virtual machine.

      Servers > Server Types > WebSphere application servers > server_name

      and then, under Server Infrastructure, click 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 the configuration, click New, and add com.ibm.websphere.webservices.DisableIBMJAXWSEngine in the Name field and true in the Value field.

Results

What to do next

• Deploy and run an application EAR file with a third-party JAX-WS implementation on WAS.

Deploy web services applications onto application servers

Related

Java virtual machine custom properties

+

Search Tips   |   Advanced Search