In certain situations you might need to set up a third-party
JAX-WS Web services engine. For example, you must set up a third-party
JAX-WS Web services engine if you need to deploy applications that
use a single runtime across various application servers such as WebSphere
Application Server, JBoss, and WebLogic, or if you want to build JAX-WS
Web services applications using third party JAX-WS run-times such
as CXF, Axis2, and Metro.
Before you begin
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 your system
to use that implementation.
The following limitations exist
regardless of which third-party JAX-WS implementation you use:
- The WebSphere Application Server runtime restricts usage of application
modules that use both the JAX-WS implementation provided with WebSphere
Application Server, and an external JAX-WS implementation in the same
application EAR file. You must use either the JAX-WS implementation
provided with WebSphere Application Server or the external implementation
in a single application EAR file. This limitation ensures that the
runtime WebSphere Application Server does not conflict with the external
third-party JAX-WS implementation.
- You must remove any conflicting JAR files from your 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 WebSphere Application
Server. This situation causes conflicts in your application library.
- After an application that uses a third-party JAX-WS runtime is
deployed on WebSphere Application Server, it is not recognized as
a service client or provider. Therefore, you cannot attach application
level policy sets to these applications. You must rely on external
runtimes support quality of service. Following is a list of WebSphere
Application Server 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.
Avoid trouble: Even though IBM supports
the enablement of third party JAX-WS runtimes to run on WebSphere
Application Server, 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.
gotcha
About this task
When you deploy an application EAR file with a third-party
JAX-WS implementation on Websphere Application Server, the Websphere
Application Server runtime must ensure the use of the third-party
engine, and disable the use of the existing Websphere Application
Server JAX-WS Web services engine.
Websphere Application Server
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.
You must complete the following steps before
you can use an external JAX-WS runtime in an application.
Procedure
- Set the class loader policy to Classes loaded
with local class loader first (parent last) at the module
level, and set the WAR Class Loader Policy to Single class
loader for application.
Changing 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 WebSphere Application Server.
- In the administrative console, click Applications
> Enterprise applications > application_name >
Class loading and update detection.
- Under Class reloading options, select Override
class reloading settings for Web and EJB modules .
- Under Class loader order, select Class loader
order property to Classes loaded with local
class loader first (parent last).
- Select Single class loader for application as
the WAR Class Loader Policy for your application.
- Click OK, and then Save to
save your changes.
- 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:
- In the administrative console, go to the Custom properties
page for the Java virtual machine.
Click server_name, and then, in the Server
Infrastructure section, click
- Set the com.ibm.websphere.webservices.DisableIBMJAXWSEngine property
to true
If this property does
not already exist for your configuration, click New,
and add com.ibm.websphere.webservices.DisableIBMJAXWSEngine in
the Name field and true in
the Value field.
What to do next
- Deploy and run an application EAR file with a third-party JAX-WS
implementation on Websphere Application Server.