TroubleShoot: JAX-WS/JAX-RPC WebSphere Web Services engine and tooling problems

 

Resources

Article	Comments
Troubleshooting web services	This IBM Docs page provides a starting point for finding information about troubleshooting during different steps of the development, assembly, deployment, and security processes of a web service.
Tracing web services	This IBM Docs task describes how to set up trace for web services on an application server, managed and unmanaged clients.
Tracing SOAP messages with tcpmon	This IBM Docs task describes how to use the tcpmon tool that is included with WebSphere to capture SOAP messages flowing to and from an HTTP port.
Tuning web services	This IBM Docs page provides a starting point for finding information about tuning web services.
Java virtual machine custom properties	This IBM Docs page contains the web services custom properties.
HTTP transport custom properties for web services applications	This IBM Docs page contains the HTTP transport custom properties for JAX-RPC and JAX-WS web services to manage the connection pool for HTTP outbound connections, configure the content encoding of the HTTP message, enable HTTP persistent connection, and resend the HTTP request when a timeout occurs.
Troubleshooting Web Services Performance Problems In IBM WebSphere Applicatio Server With Web Services Performance (WSPerf) Trace	This IBM Developer article describes how to use the WebSphere Application Server WSPerf trace tool to analyze the speed of web services message traffic in the web services engine. WSPerf trace helps to narrow down likely suspects for root-cause problem determination

 

Where can I find the custom properties for Web Services?

Most of the web services custom properties are set as JVM custom properties. They can be found in the IBM Documentation article Java virtual machine custom properties. Most of the Web Services custom properties have either webservices or websvcs in the name.

 

How can I set up trace for a managed client (launchclient)?

Enable trace for a web services managed client by invoking the launchClient command-line tool with the following options:

-CCtrace=com.ibm.ws.webservices.engine.*=all=enabled -CCtracefile=traceFileName

For example:

%install_root%\bin\launchClient MyAppClient.ear -CCtrace=com.ibm.ws.webservices.engine.*=all=enabled -CCtracefile=myAppClient.log

This creates the trace and puts the results in myAppClient.log

More information-managed client tracing can be found in the IBM Documentation: launchClient tool.


 

How can I set up trace for an unmanaged client (thinclient)?

Information on how to set up trace for an unmanaged client can be found in the IBM Documentation: Enabling trace on client and stand-alone applications

Notes:

• Do not forget to put the directory that contains the trace settings property file in your classpath (ex: you can create a folder in your Eclipse project and place the trace settings file in there).
• The property to enable trace is -DtraceSettingsFile=TraceSettings.properties, and the file name must not be fully qualified.
• In addition to the JVM system property -DtraceSettingsFile=TraceSettings.properties for your java invocation, you also need to specify these properties as well:

  -Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager -Djava.util.logging.configureByServer=true

• Apache commons logging can interfere with WebSphere's client logging. Stand-alone Java Web services client trace output appears, but it is not complete. Resolution: Disable use of Apache commons logging.
• An example of TraceSettings.properties is in (was_home)/properties/TraceSettings.properties
• Here is an example of the TraceSettings.properties file:

  # A property to specify where the output messages and trace (if enabled) # should be routed. Valid values include stdout or a fully qualified # file name. If a file is specified but cannot be opened, stdout is used. # # Sample invocations # To specify stdout - traceFileName=stdout # To specify a file on NT - traceFileName=c:\\MyTraceFile.log or # traceFileName=c:/MyTraceFile.log # To specify a file on Unix - traceFileName=/usr/MyTraceFile.log traceFileName=c:\\ClientTrace_60225\\ClientTrace.log # Specify trace strings here. Trace strings take the form of: # logger={level}={type} where: # level = entryexit || debug || event || all # type = enabled || disabled # examples: # com.ibm.ejs.ras.SharedLogBase=all=enabled enables all tracing for the # single logger created in class com.ibm.ejs.ras.SharedLogBase. # com.ibm.ejs.*=debug=enabled enables debug tracing for all loggers with # names starting with com.ibm.ejs. # # Multiple trace strings can be specified, one per line. #com.ibm.ejs.ras.*=all=enabled com.ibm.ws.webservices.*=all=enabled

 

How can I set up trace for a JAX-WS unmanaged client (thinclient) in Eclipse?

Following is how to set up a JAX-WS unmanaged client (thinclient) trace in Eclipse:

 Create your TraceSettings.properties as described above and place it in a directory on the Eclipse machine

1. In the run configuration, Classpath tab, do the following:
   1. Click user entries
   2. Click Advanced
   3. Select Add External Folders
   4. Browse to the folder that contains your TraceSettings.properties file
2. In the run configuration, Arguments tab, add the following VM arguments:

   -DtraceSettingsFile=TraceSettings.properties -Djava.util.logging.manager=com.ibm.ws.bootstrap.WsLogManager -Djava.util.logging.configureByServer=true

 

How do I run a JAX-WS unmanaged client (thinclient) in Ecliplse?

To build/run a JAX-WS unmanaged client (thinclient) in Eclipse, you must add the JAX-WS thinclient jar to the application's build class path. In Eclipse, do the following: 

1. Bring up the properties for the application
2. Click Java Build Path
3. Click the Libraries tab
4. Click Add External JARs
5. Browse to (was_home)\run times\com.ibm.jaxws.thinclient_x.x.0.jar
6. If your application doesn't compile cleanly with just the jaxws.thinclient jar, you might want to try adding the following:
   • (was_home)\plugins\com.ibm.wsspi.rrd.jar
   • (was_home)\plugins\com.ibm.wsspi.extension.jar
   • (was_home)\plugins\com.ibm.wsspi.proxy.extension.jar

 

How can I see the SOAP messages without a wire trace?

The com.ibm.ws.webservices.trace.*=all:com.ibm.ws.websvcs.trace.*=all elements in the Web Services trace spec ensure that the inbound and outbound SOAP messages are logged to the trace.log file. The former is for JAX-RPC and the latter is for JAX-WS. If all you want to see is your SOAP messages, this is the only trace setting that you need.

WSWS3569I: Inbound {0} {1} request: WSWS3570I: Inbound {0} {1} response: WSWS3571I: Outbound {0} {1} request: WSWS3572I: Outbound {0} {1} response:

How can I tell if an application is JAX-WS or JAX-RPC from a trace?

There are several ways to tell if an application is JAX-WS or JAX-RPC:

• When you have a web services trace spec active on your application server, as documented on the Collect data tab, you can easily see whether a provider application is JAX-WS or JAX-RPC when the application loads. The application must be started within the timeframe of the trace; this usually means that the trace must have been obtained from server startup.
  • Here is an example of the output from a JAX-WS provider application:

    [1/10/18 16:38:30:359 CST] 00000076 WSModuleDescr < _containsJAXWSWebServices, module= HelloSvc.war: true Exit [1/10/18 16:38:30:359 CST] 00000076 DualMetaDataL 3 isWebServiceEnabled: Application HelloJaxws70.ear/deployments/HelloJaxws70 is enabled.

  • Here are examples of the output from a JAX-RPC provider application:

    [1/10/18 16:38:57:250 CST] 0000007b WSModuleDescr < _containsJAXWSWebServices, module= HelloSvc.war: false Exit [1/10/18 16:38:57:250 CST] 0000007b JAXRPCMetaDat > loadJAXRPCMetaData Entry   [1/10/18 16:38:57:250 CST] 0000007b WSModuleDescr < _containsJAXRPCWebServices, module= HelloSvc.war: true Exit [1/10/18 16:38:57:250 CST] 0000007b DualMetaDataL 3 isWebServiceEnabled: Application HelloSvcEAR.ear/deployments/HelloSvcEAR is enabled.

• At run time, both the JAX-RPC client and provider, have many trace statements from the P2DConverter and PivotHandlerWrapper classes. For example:

  [1/10/18 16:39:06:968 CST] 00000078 P2DConverter 1 com.ibm.ws.webservices.engine.events.P2DConverter debugMessage start startElement1:InclusiveNamespaces   [1/10/18 16:39:07:390 CST] 0000007b PivotHandlerW 1 com.ibm.ws.webservices.engine.PivotHandlerWrapper preHandleIncoming PivotHandlerWrapper.getPivotHandler().preHandleIncoming()

• If you page through a runtime trace for either a JAX-WS client or provider, you'll see sets of DEBUG_FRAME outputs. For example:

  [1/10/18 16:38:39:921 CST] 0000007a SOAPHeadersAd 3 org.apache.axis2.jaxws.handler.SOAPHeadersAdapter install Installing SOAPHeadersAdapter: DEBUG_FRAME = org.apache.axis2.util.JavaUtils.callStackToString(JavaUtils.java:564) DEBUG_FRAME = org.apache.axis2.jaxws.handler.SOAPHeadersAdapter.install(SOAPHeadersAdapter.java:82) DEBUG_FRAME = org.apache.axis2.jaxws.message.util.MessageUtils.putMessageOnMessageContext(MessageUtils.java:226) DEBUG_FRAME = org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.prepareRequest(AxisInvocationController.java:380) DEBUG_FRAME = org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:92) DEBUG_FRAME = org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:419) DEBUG_FRAME = org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:213)

• JAX-WS client and provider applications have many references to classes in the org.apache packages at run time. Examples:

  [1/10/18 16:38:41:406 CST] 00000074 BuilderUtil 1 org.apache.axis2.builder.BuilderUtil getCharSetEncoding Input contentType (text/xml; charset=UTF-8)   [1/10/18 16:38:41:406 CST] 00000074 StAXUtils 1 org.apache.axiom.om.util.StAXUtils getXMLInputFactory_perClassLoader About to create XMLInputFactory implementation with classloader=

 

How can I make sure that my JAX-RPC application is JSR-109 compliant?

The com.ibm.ws.webservices.multiprotocol.AgnosticService=all element in the Web Services trace spec ensures that JSR-109 information is emitted for a JAX-RPC application in fix packs 7.0.0.3 and later. If your application is JSR-109 compliant, you can see a trace statement like:

[3/26/16 13:43:22:720 CET] 00000094 AgnosticServi 3 Is client JSR-109-compliant? true

If not, the statement is false.

If you find something like the following in your client trace logs, odds are that you are not using the JNDI lookup that is required for JSR-109 compliance:

[10/13/16 14:33:58:584 EDT] 00000026 AgnosticServi > getStub Entry

Here is some information for ensuring that your JAX-RPC application is JSR-109 compliant:

Implementing JAX-RPC web services clients
PK50158: INFORMATION CENTER SAYS THAT JSR-109 WEBSERVICES CLIENTS SHOULD BE USED, BUT IT IS NOT DOCUMENTED HOW TO PROGRAM SUCH A CLIENT

If the client code is using a Rational Application Developer (RAD) or an Eclipse proxy class, it is supposed to use a JNDI lookup. However, in many RAD proxies, even if you have useJNDI=true, if an exception occurs during the JNDI lookup, it reverts to the 'new servicelocator' method. The only way to tell if this has happened is to edit your proxy to report if you get an exception during the JNDI lookup, print a stacktrace, then exit the method entirely.

For example:

Turn off automatic file overwriting Edit your *proxy.java file Ensure that the string on your ctx.lookup is correct. If it isn't, fix it In the catch blocks immediately after the ctx.lookup, where it is eating the NamingException and ServiceException, put something similar to the following for each block: catch (javax.naming.NamingException namingException ex) { System.out.println("namingException occurred: "+ex); ex.printStackTrace(); } Remove the entire (serviceVar) == null block since you don't want to run at all without jndi. (or, you could change it to): if ( __hello == null && _useJNDI == false) After you redeploy, look at the proxy again and make sure RAD hasn't overwritten your updates.

If you generate a proxy with RAD 7.5 or later, you can set both useJNDI=true and useJNDIOnly=true. This prevents the proxy from using the service locator.


 

How do I fix slow JAXBContext creation problems?

A search of the classloader for potential JAXB classes is performed every time a web services application is started. If the search process for your application is lengthy, there are ways to reduce the amount of time the system spends creating the JAXBContext for your application.

More information can be found in the IBM Docs article Reducing the time required to create the JAXBContext.

 

You can't use /?wsdl in WebSphere
Fail to access wsdl file with URL http://(host):(port)/(contextRoot)/(url_pattern)/?wsdl

By default, WebSphere does not support accessing a URL that ends with "/?wsdl". You can enable the access by modifying your servlet mapping to include a wildcard like this example:

<servlet-mapping><servlet-name>AxisServlet</servlet-name><url-pattern>/servlet/AxisServlet/*</url-pattern></servlet-mapping>