You are on page 1of 12

Troubleshooting JAX-WS applications with the

WebSphere Application Server V6.1 Feature Pack for


Web Services
Phil Adams (phil_adams@us.ibm.com) April 02, 2008
Senior Software Engineer
IBM

Learn some tips and techniques for troubleshooting the IBM WebSphere Application Server
V6.1 Feature Pack for Web Services, including common error conditions and suggested
methods for correcting them.

The WebSphere Application Server V6.1 Feature Pack for Web Services (hereafter called the
WSFP) introduced support for the Java API for XML Web Services (JAX-WS) programming
model and the Java Architecture for XML Binding (JAXB) data binding model. JAX-WS
provides a client programming model that includes an API for invoking Web service operations
asynchronously, and enables you to use annotations to specify application metadata that would
normally appear in deployment descriptor files.

This article describes some basic techniques that can be used to diagnose various problems that
might occur while installing, deploying, and executing JAX-WS Web services applications. Well
look at how to trace application initialization, how to trace SOAP messages, and how to interpret
common error conditions.

To get the most from this article, you should have a basic understanding of the WSFP and the
JAX-WS programming model, as well as how to use the WebSphere Application Server (hereafter
called Application Server) administrative console.

Capturing trace information for JAX-WS applications


Deliver new web apps fast!

Try building and deploying your next project on the IBM Bluemix cloud platform, where
you can take advantage of pre-built services, runtimes, frameworks, application lifecycle
management, and continuous integration.

Sign up for a free trial

Copyright IBM Corporation 2008 Trademarks


Troubleshooting JAX-WS applications with the WebSphere Page 1 of 12
Application Server V6.1 Feature Pack for Web Services
developerWorks ibm.com/developerWorks/

Application Server provides a facility for capturing detailed information about the operation and
progress of the server and applications. The Application Server Information Center includes
several topics about this tracing facility, including the topic Tracing Web services, which discusses
how to enable tracing for the JAX-RPC Web services engine.

Capturing trace information for the JAX-WS Web services engine is similar to the JAX-RPC
engine, except that you can use several different trace strings:

Table 1. JAX-WS trace strings


This trace string: enables trace for this component:

com.ibm.ws.websvcs.*=all Integration layer (the set of classes that provide integration of the Axis2/
JAX-WS run-time in the Application Server environment)

com.ibm.ws.policyset.*=all Policyset component

com.ibm.ws.wssecurity.*=all WS-Security component

com.ibm.ws.wsaddressing.*=all WS-Addressing component

com.ibm.ws.wstx.*=all WS-Transactions component

org.apache.axis2.jaxws.*=all JAX-WS run-time

org.apache.axis2.*=all Axis2 run-time (including JAX-WS)

To use the Application Server administrative console to set one or more of these trace strings, do
the following:

1. Start Application Server, then open the administrative console.


2. From the main window, select Application Servers => server1 => Diagnostic Trace
Service > Change Log Detail Levels as shown in Figure 1.
Figure 1. Use the administrative console to set the trace string for an
application server

Troubleshooting JAX-WS applications with the WebSphere Page 2 of 12


Application Server V6.1 Feature Pack for Web Services
ibm.com/developerWorks/ developerWorks

3. In the Properties window, you can select from a list of predefined trace strings, or enter
your own trace string directly into the entry field, as shown in Figure 1. For example,
to enable tracing for the integration layer and the JAX-WS run-time, you would enter
com.ibm.ws.websvcs.*=all:org.apache.axis2.jaxws.*=all in the entry field, as shown in
Figure 2.
Figure 2. Turning on tracing in the JAX-WS run-time and in the Application
Server integration layer

Tracing application initialization


One common use of the tracing facility is to examine the details of application initialization. By
capturing a trace of your application as it starts, you can make sure that it is initialized properly and
that your Web service endpoints are, in fact, available at the endpoint addresses that you intended.

Suppose that you set a trace string for your application server as in Figure 2, and that you have
installed the JAX-WS sample application. When the application starts, you would see trace
messages similar to Listing 1 in the application servers trace.log file.

Note that the messages in bold show the URL patterns associated with the endpoints contained
in your Web service application. These are the URL patterns that client applications use to access
those endpoints. For example, if a client application invokes an operation on the EchoService
endpoint (com.ibm.was.wssample.sei.echo.EchoServicePortImpl implementation class, it would
use an endpoint such as http://MyHost:9080/WSSampleSei/EchoService.

Listing 1. Example trace messages showing application initialization


[2/19/08 23:25:38:515 CST] 0000001d ApplicationMg A WSVR0200I: Starting application:
WSSampleServicesSei
...

[2/19/08 23:25:39:156 CST] 0000001d WebGroup A SRVE0169I: Loading Web Module:


SampleServicesSei.
[2/19/08 23:25:39:171 CST] 0000001d WASAxis2Exten 3 Extension Processor is being
created for module: SampleServicesSei.war of application: WSSampleServicesSei
[2/19/08 23:25:39:171 CST] 0000001d WASAxis2Exten > WASAxis2ExtensionProcessor
ctor Entry
...

[2/19/08 23:25:39:171 CST] 0000001d WASAxis2Exten > createServletConfigs,

Troubleshooting JAX-WS applications with the WebSphere Page 3 of 12


Application Server V6.1 Feature Pack for Web Services
developerWorks ibm.com/developerWorks/

module=SampleServicesSei.war Entry
[2/19/08 23:25:39:171 CST] 0000001d WASAxis2Exten 3 Created new servlet,
name=com.ibm.was.wssample.sei.ping.PingService12PortImpl,
class=com.ibm.ws.websvcs.transport.http.WASAxis2Servlet
[2/19/08 23:25:39:171 CST] 0000001d WASAxis2Exten > checkServletMappings,
servlet=com.ibm.was.wssample.sei.ping.PingService12PortImpl,
service=PingService12.PingService12Port Entry
[2/19/08 23:25:39:171 CST] 0000001d ServletWrappe I
SRVE0242I: [WSSampleServicesSei] [/WSSampleSei]
[com.ibm.was.wssample.sei.ping.PingService12PortImpl]: Initialization successful.
[2/19/08 23:25:39:171 CST] 0000001d WASAxis2Exten I
WSWS7037I: The /PingService12 URL pattern was configured for the
com.ibm.was.wssample.sei.ping.PingService12PortImpl servlet located in the
SampleServicesSei.war web module.
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3 Servlet
[com.ibm.was.wssample.sei.ping.PingService12PortImpl] has the following mappings:
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3
[0]: com.ibm.was.wssample.sei.ping.PingService12PortImpl:/PingService12
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3
[1]: com.ibm.was.wssample.sei.ping.PingService12PortImpl:/PingService12/wsdl/*
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3
[2]: com.ibm.was.wssample.sei.ping.PingService12PortImpl:*.xsd
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3
[3]: com.ibm.was.wssample.sei.ping.PingService12PortImpl:*.wsdl
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten < checkServletMappings Exit
...

[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3


Created new servlet, name=com.ibm.was.wssample.sei.echo.EchoService12PortImpl,
class=com.ibm.ws.websvcs.transport.http.WASAxis2Servlet
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten > checkServletMappings,
servlet=com.ibm.was.wssample.sei.echo.EchoService12PortImpl,
service=EchoService12.EchoService12Port Entry
[2/19/08 23:25:39:187 CST] 0000001d ServletWrappe I
SRVE0242I: [WSSampleServicesSei] [/WSSampleSei]
[com.ibm.was.wssample.sei.echo.EchoService12PortImpl]: Initialization successful.
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten I
WSWS7037I: The /EchoService12 URL pattern was configured for the
com.ibm.was.wssample.sei.echo.EchoService12PortImpl servlet located in the
SampleServicesSei.war web module.
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3 Servlet
[com.ibm.was.wssample.sei.echo.EchoService12PortImpl] has the following mappings:
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3
[0]: com.ibm.was.wssample.sei.echo.EchoService12PortImpl:/EchoService12
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3
[1]: com.ibm.was.wssample.sei.echo.EchoService12PortImpl:/EchoService12/wsdl/*
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3
[2]: com.ibm.was.wssample.sei.echo.EchoService12PortImpl:*.xsd
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3
[3]: com.ibm.was.wssample.sei.echo.EchoService12PortImpl:*.wsdl
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten < checkServletMappings Exit
...

[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten 3 Created new servlet,


name=com.ibm.was.wssample.sei.ping.PingServicePortImpl,
class=com.ibm.ws.websvcs.transport.http.WASAxis2Servlet
[2/19/08 23:25:39:187 CST] 0000001d WASAxis2Exten > checkServletMappings,
servlet=com.ibm.was.wssample.sei.ping.PingServicePortImpl,
service=PingService.PingServicePort Entry
[2/19/08 23:25:39:203 CST] 0000001d ServletWrappe I SRVE0242I: [WSSampleServicesSei]
[/WSSampleSei] [com.ibm.was.wssample.sei.ping.PingServicePortImpl]:
Initialization successful.
[2/19/08 23:25:39:203 CST] 0000001d WASAxis2Exten I WSWS7037I: The /PingService URL
pattern was configured for the com.ibm.was.wssample.sei.ping.PingServicePortImpl servlet
located in the SampleServicesSei.war web module.
[2/19/08 23:25:39:203 CST] 0000001d WASAxis2Exten 3
Servlet [com.ibm.was.wssample.sei.ping.PingServicePortImpl] has the following mappings:

Troubleshooting JAX-WS applications with the WebSphere Page 4 of 12


Application Server V6.1 Feature Pack for Web Services
ibm.com/developerWorks/ developerWorks

[2/19/08 23:25:39:203 CST] 0000001d WASAxis2Exten 3


[0]: com.ibm.was.wssample.sei.ping.PingServicePortImpl:/PingService
[2/19/08 23:25:39:203 CST] 0000001d WASAxis2Exten 3
[1]: com.ibm.was.wssample.sei.ping.PingServicePortImpl:/PingService/wsdl/*
[2/19/08 23:25:39:203 CST] 0000001d WASAxis2Exten 3
[2]: com.ibm.was.wssample.sei.ping.PingServicePortImpl:*.xsd
[2/19/08 23:25:39:203 CST] 0000001d WASAxis2Exten 3
[3]: com.ibm.was.wssample.sei.ping.PingServicePortImpl:*.wsdl
[2/19/08 23:25:39:203 CST] 0000001d WASAxis2Exten < checkServletMappings Exit
...

[2/19/08 23:25:39:203 CST] 0000001d WASAxis2Exten 3 Created new servlet,


name=com.ibm.was.wssample.sei.echo.EchoServicePortImpl,
class=com.ibm.ws.websvcs.transport.http.WASAxis2Servlet
[2/19/08 23:25:39:203 CST] 0000001d WASAxis2Exten >
checkServletMappings, servlet=com.ibm.was.wssample.sei.echo.EchoServicePortImpl,
service=EchoService.EchoServicePort Entry
[2/19/08 23:25:39:218 CST] 0000001d ServletWrappe I
SRVE0242I: [WSSampleServicesSei] [/WSSampleSei]
[com.ibm.was.wssample.sei.echo.EchoServicePortImpl]: Initialization successful.
[2/19/08 23:25:39:218 CST] 0000001d WASAxis2Exten I
WSWS7037I: The /EchoService URL pattern was configured for the
com.ibm.was.wssample.sei.echo.EchoServicePortImpl servlet located in the
SampleServicesSei.war web module.
[2/19/08 23:25:39:218 CST] 0000001d WASAxis2Exten 3
Servlet [com.ibm.was.wssample.sei.echo.EchoServicePortImpl] has the following mappings:
[2/19/08 23:25:39:218 CST] 0000001d WASAxis2Exten 3
[0]: com.ibm.was.wssample.sei.echo.EchoServicePortImpl:/EchoService
[2/19/08 23:25:39:218 CST] 0000001d WASAxis2Exten 3
[1]: com.ibm.was.wssample.sei.echo.EchoServicePortImpl:/EchoService/wsdl/*
[2/19/08 23:25:39:218 CST] 0000001d WASAxis2Exten 3
[2]: com.ibm.was.wssample.sei.echo.EchoServicePortImpl:*.xsd
[2/19/08 23:25:39:218 CST] 0000001d WASAxis2Exten 3
[3]: com.ibm.was.wssample.sei.echo.EchoServicePortImpl:*.wsdl
[2/19/08 23:25:39:218 CST] 0000001d WASAxis2Exten < checkServletMappings Exit
[2/19/08 23:25:39:218 CST] 0000001d WASAxis2Exten < createServletConfigs Exit
[2/19/08 23:25:39:218 CST] 0000001d WASAxis2Exten < WASAxis2ExtensionProcessor ctor Exit
[2/19/08 23:25:39:234 CST] 0000001d VirtualHost I SRVE0250I:
Web Module SampleServicesSei has been bound to default_host
[*:9080,*:80,*:9444,*:5063,*:5062,*:443].
[2/19/08 23:25:39:234 CST] 0000001d ApplicationMg A
WSVR0221I: Application started: WSSampleServicesSei

Tracing SOAP messages


You can also use the tracing facility to trace SOAP messages. Using a trace string of
com.ibm.ws.websvcs.trace.*=all enables you to view the SOAP messages that flow between the
client and server.

Listing 2 shows the request and response messages that result from running the JAX-WS sample
application that is included with the WSFP.

Note: The SOAP message tracing feature was introduced in the WSFP 6.1.0.13 Fix Pack, so
youll need to install that fix pack to use the SOAP message tracing capability.

Listing 2. Example of SOAP message tracing


[2/27/08 23:31:44:468 CST] 0000001e MessageTrace 3 WSWS3571I: Outbound HTTP SOAP
request:
Content-Type: text/xml
Message contents:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

Troubleshooting JAX-WS applications with the WebSphere Page 5 of 12


Application Server V6.1 Feature Pack for Web Services
developerWorks ibm.com/developerWorks/

<soapenv:Body><ns2:echoStringInput
xmlns:ns2="http://com/ibm/was/wssample/sei/echo/"><echoInput>
This is a test of the JAX-WS sample application
</echoInput></ns2:echoStringInput></soapenv:Body></soapenv:Envelope>
[2/27/08 23:31:44:687 CST] 0000001c MessageTrace 3
WSWS3569I: Inbound HTTP SOAP request:
Content-Type: text/xml; charset=UTF-8
Message contents:
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body><ns2:echoStringInput
xmlns:ns2="http://com/ibm/was/wssample/sei/echo/"><echoInput>
This is a test of the JAX-WS sample application</echoInput></ns2:echoStringInput>
</soapenv:Body></soapenv:Envelope>
[2/27/08 23:31:45:203 CST] 0000001c MessageTrace 3
WSWS3572I: Outbound HTTP SOAP response:
Content-Type: text/xml
Message contents:
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body>
<ns2:echoStringResponse xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">
<echoResponse>JAX-WS==>>
This is a test of the JAX-WS sample application</echoResponse></ns2:echoStringResponse>
</soapenv:Body></soapenv:Envelope>
[2/27/08 23:31:45:218 CST] 0000001e MessageTrace 3
WSWS3570I: Inbound HTTP SOAP response:
Content-Type: text/xml
Message contents:
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"><soapenv:Body>
<ns2:echoStringResponse xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">
<echoResponse>JAX-WS==>>
This is a test of the JAX-WS sample application</echoResponse></ns2:echoStringResponse>
</soapenv:Body></soapenv:Envelope>

Another way to view SOAP request and response messages is to use the TCPMON utility that
is shipped with Application Server. For information on how to use TCPMON, see Tracing SOAP
messages with TCPMON in the WebSphere Application Server Information Center.

Fixing common error conditions


This section describes some common errors that WSFP users may encounter, and steps you can
take to correct them.

Annotation validation errors within a WAR module


Problem: Annotation validation errors occur during the loading of a WAR module containing JAX-
WS Web service endpoints.

Symptoms: A WAR module does not start correctly. You might see errors like the following in the
SystemOut.log file:
[8/13/07 22:14:38:140 CDT] 0000001c WASAxis2Compo E WSWS7007E: The
SampleServicesSei.war application module cannot be loaded correctly
because of the following error:
javax.xml.ws.WebServiceException: Validation error: Implementation
subclass does not implement method on specified interface.
Implementation class: com.ibm.was.wssample.sei.echo.EchoService12PortImpl;
missing method name: echoOperation12; endpointInterface:
com.ibm.was.wssample.sei.echo.EchoService12PortType
at

Troubleshooting JAX-WS applications with the WebSphere Page 6 of 12


Application Server V6.1 Feature Pack for Web Services
ibm.com/developerWorks/ developerWorks

org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException
(ExceptionFactory.java:178)
at
org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException
(ExceptionFactory.java:79)
at
org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException
(ExceptionFactory.java:125)
at
org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateImplementation
(ServiceDescriptionImpl.java:1045)
at
org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateIntegrity
(ServiceDescriptionImpl.java:853)
at
org.apache.axis2.jaxws.description.impl.ServiceDescriptionImpl.validateDBCLIntegrity
(ServiceDescriptionImpl.java:707)

Solution: The error message in the log should indicate the area that has failed validation. Consult
the logs and make any needed changes to the annotated classes, WSDL, or XSD.

A module contains annotated JAX-WS endpoint classes with clashing


@WebService.serviceName values
Problem: Two service implementation bean classes in a single module have the
same @WebService.serviceName value, but different @WebService.portName or
@WebService.targetNamespace values. The application starts, but only one of the two endpoints
can be reached due to the way in which an endpoints URL pattern is determined.

Symptoms: Only one of the two endpoints is available via http. The server's SystemOut.log will
contain an entry like the following:
[8/14/07 7:19:50:225 CDT] 0000001b WASAxis2Exten E
WSWS7031E: The java.lang.Exception: Mapping clash for ServletWrapper
[com.ibm.was.wssample.sei.echo.EchoService12PortImpl:null]:
Target ServletWrapper
[com.ibm.was.wssample.sei.echo.EchoService12PortTwoImpl:
[com.ibm.was.wssample.sei.echo.EchoService12PortTwoImpl:
/EchoService12, com.ibm.was.wssample.sei.echo.EchoService12PortTwoImpl:
/EchoService12/wsdl/*,
com.ibm.was.wssample.sei.echo.EchoService12PortTwoImpl:
*.xsd, com.ibm.was.wssample.sei.echo.EchoService12PortTwoImpl:
*.wsdl]] already exists at node /

Note: This error occurs because the default URL pattern for an implementation class is http://
<host>:<port>/<module_context_root>/<@WebService.serviceName>. Since both implementation
classes have the same @WebService.serviceName, the Web container reports a mapping clash and
the default URL pattern cannot be established for the second endpoint.

Solution: Define unique URL patterns for the different endpoints in the modules web.xml file.
You can find more information about how to do this in the Information Center topic Customizing
URL patterns in the web.xml file for JAX-WS applications.

Troubleshooting JAX-WS applications with the WebSphere Page 7 of 12


Application Server V6.1 Feature Pack for Web Services
developerWorks ibm.com/developerWorks/

Application fails to start because of problems finding WSDL or schema files


Problem: An application fails to start due to a FileNotFoundException. This happens when a
WSDL or schema (.xsd) file can't be found.

Symptoms: An error message like the following will appear in the servers SystemOut.log file:
0000001c WASAxis2Compo E WSWS7007E: The SampleServicesSei.war
application module cannot be loaded correctly because of the following
error: java.lang.Exception: Configuration data could not be created for
the Web service related class
com/ibm/was/wssample/sei/echo/EchoService12PortImpl :
com.ibm.ws.websvcs.exception.DeploymentException:
java.io.FileNotFoundException:
C:\wasx\as\profiles\AppSrv01\installedApps\IBM-D81F2830B1ENode01Cell\
WSSampleServicesSei.ear\SampleServicesSei.war\WEB-INF\wsdl\Ech.wsdl
(The system cannot find the file specified.)
at com.ibm.ws.websvcs.annotations.generator.
WASAnnotationInputBuilder.buildInputs(WASAnnotationInputBuilder.java:186)

Solution: Ensure that the WSDL document referenced by the Web service implementation's
@WebService.wsdlLocation value is in the specified location, and that any imported WSDL and
schema (.xsd) files are in their specified locations.

JAX-WS service clients do not appear in the administrative console Service


Clients list
Problem: JAX-WS service clients in a deployed WAR module do not appear in the administrative
console Service Clients list

Symptoms: The client functions properly, but doesn't appear in the administrative console list.
This prevents users from attaching policy sets to the client using the administrative console. A
com.ibm.ws.websvcs.*=all trace would yield a warning message like the following:

WSModuleDescr W WSWS7062E: The c:/wsdl/WEB-INF/wsdl/Echo12.wsdl


Web Services Description Language (WSDL) file referenced by the
@WebServiceClient annotation in the
com/ibm/was/wssample/sei/echo/EchoService12 class could not be loaded

If the client does not show up in the console listing, and there is no warning message
in the server's trace log like the message above, ensure that the JAX-WS client has an
@WebServiceClient annotation. If the client was properly recognized by the run-time, the following
trace message will be logged: @WebServiceClient annotation processed: EchoService.

Solution: Although this won't prevent the client from functioning properly, it limits the ability
of users to configure the client with policy sets using the administrative console. To ensure
that a JAX-WS client appears in the administrative console, ensure that it is annotated with
@WebServiceClient and that the wsdlLocation attribute value specifies a valid WSDL document.

Connection refused error when invoking a Web service


Problem: An application containing a JAX-WS Web service was successfully installed, but
attempts to invoke the Web service fail.

Troubleshooting JAX-WS applications with the WebSphere Page 8 of 12


Application Server V6.1 Feature Pack for Web Services
ibm.com/developerWorks/ developerWorks

Symptoms: The client receives the following error and the Web service invocation fails:
javax.xml.ws.WebServiceException: java.net.ConnectException:
Connection refused: no further information
at
org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException
(ExceptionFactory.java:180)
at
org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException
(ExceptionFactory.java:79)
at
org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException
(ExceptionFactory.java:134)
at
org.apache.axis2.jaxws.core.controller.AxisInvocationController.execute
(AxisInvocationController.java:595)

Solution: First, make sure that the client is using the correct endpoint to invoke the Web service
(correct host, port, context root, and URL pattern). It's also possible that the application installed
successfully, but did not start successfully. Errors that occurred during the start of the application
would be present in the SystemOut.log or SystemErr.log, as well as the trace.log, if trace was
enabled. A Web services trace (com.ibm.ws.websvcs.*=all) of the server can help you determine
whether the application is starting correctly and which URL patterns were used with the various
endpoints. Here is an example:
[8/15/07 12:56:53:296 CDT] 00000014 WASAxis2Exten 3
Added mapping [/PingService12] for servlet
[com.ibm.was.wssample.sei.ping.PingService12PortImpl]

This indicates that the WASAxis2ExtensionProcessor class has created a URL


pattern /PingService12, which is associated with the Web service implementation class
com.ibm.was.wssample.sei.ping.PingService12PortImpl.

The asynchronous response servlet does not start properly


Problem: The async response servlet does not start properly.

Symptoms: You'll see error messages in the SystemOut.log file similar to these:
[8/13/07 14:15:57:550 CDT] 0000001b SystemErr R
org.apache.axis2.AxisFault:
WSWS7115E: The required AsyncResponseServlet is not available.
[8/13/07 14:15:57:550 CDT] 0000001b SystemErr R
at
com.ibm.ws.websvcs.transport.http.AsyncResponseServletListener.
getEPRsForService(AsyncResponseServletListener.java:114)
[8/13/07 14:15:57:550 CDT] 0000001b SystemErr R
at
org.apache.axis2.engine.ListenerManager.getEPRforService
(ListenerManager.java:102)
[8/13/07 14:15:57:550 CDT] 0000001b SystemErr R
at org.apache.axis2.description.OutInAxisOperationClient.execute
(OutInAxisOperation.java:243)

Troubleshooting JAX-WS applications with the WebSphere Page 9 of 12


Application Server V6.1 Feature Pack for Web Services
developerWorks ibm.com/developerWorks/

Solution: This type of error normally indicates that the async response servlet application
(ibmasyncrsp.ear) was not properly installed, which implies that the Application Servers profile
was not created correctly.

1. Make sure that the async response servlet application is installed and starts up properly. You
should see messages in the SystemOut.log similar to these when the Application Server
starts up:
[8/15/07 13:37:16:437 CDT] 00000013 ApplicationMg A
WSVR0200I: Starting application: ibmasyncrsp
[8/15/07 13:37:16:437 CDT] 00000013 ApplicationMg A
WSVR0203I: Application: ibmasyncrsp Application build level:
WSFP.WSERV1 [x0724.11]
[8/15/07 13:37:17:484 CDT] 00000013 webapp
I com.ibm.ws.webcontainer.webapp.WebGroupImpl WebGroup
SRVE0169I: Loading Web Module: WebSphere ASYNC Response
Servlet Application.
[8/15/07 13:37:17:609 CDT] 00000013 servlet
I com.ibm.ws.webcontainer.servlet.ServletWrapper init
SRVE0242I: [ibmasyncrsp] [/IBM_WS_SYS_RESPONSESERVLET]
[rspservlet]: Initialization successful.
[8/15/07 13:37:17:703 CDT] 00000013 ApplicationMg A
WSVR0221I: Application started: ibmasyncrsp
2. Make sure that your application server profile was created correctly.

Inconsistent SSL configuration


Problem: A client tries to access a Web service that has been configured with SSL, but the client
does not have SSL configured.

Symptoms: You will see error messages similar to the following:


[8/13/07 13:42:59:516 CDT] 0000001c SetupSSLConfi 3
exception01 java.security.PrivilegedActionException:
org.apache.axis2.AxisFault: WSWS7130E: No Secure Sockets Layer (SSL)
configuration is available for the
https://localhost:9443/WSSampleSei/EchoService endpoint.
at java.security.AccessController.doPrivileged
(AccessController.java:246)
at com.ibm.ws.security.util.AccessController.doPrivileged
(AccessController.java:125)
at com.ibm.ws.websvcs.transport.http.SetupSSLConfiguration.
setupEffectiveSSLConfiguration(SetupSSLConfiguration.java:69)
at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.
setupHTTPConnection(SOAPOverHTTPSender.java:1483)
at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.
is302or401set(SOAPOverHTTPSender.java:952)
at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.
send(SOAPOverHTTPSender.java:377)

Solution: Make sure that SSL is configured on the client.

Web service invocation times out


Problem: The client encounters a timeout when waiting for a response message to arrive from the
server.

Symptoms: You will see error messages similar to the following:

Troubleshooting JAX-WS applications with the WebSphere Page 10 of 12


Application Server V6.1 Feature Pack for Web Services
ibm.com/developerWorks/ developerWorks

[8/15/07 15:20:35:202 CDT] 0000001b SystemErr R


Caused by: java.net.SocketTimeoutException: Async operation timed out
at com.ibm.ws.tcp.channel.impl.AioTCPReadRequestContextImpl.
processSyncReadRequest(AioTCPReadRequestContextImpl.java:157)
at com.ibm.ws.tcp.channel.impl.TCPReadRequestContextImpl.
read(TCPReadRequestContextImpl.java:109)
at com.ibm.ws.http.channel.outbound.impl.
HttpOutboundServiceContextImpl.parseResponseMessageSync
(HttpOutboundServiceContextImpl.java:1627)
at com.ibm.ws.http.channel.outbound.impl.
HttpOutboundServiceContextImpl.readSyncResponse
(HttpOutboundServiceContextImpl.java:702)
at com.ibm.ws.http.channel.outbound.impl.
HttpOutboundServiceContextImpl.startResponseReadSync
(HttpOutboundServiceContextImpl.java:1745)
at com.ibm.ws.http.channel.outbound.impl.
HttpOutboundServiceContextImpl.finishRequestMessage
(HttpOutboundServiceContextImpl.java:1164)
at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.
sendSOAPRequest(SOAPOverHTTPSender.java:492)

Solution: Try to determine why it's taking so long for the response to arrive at the client. If it's
due to a problem on the server, you should be able to determine this by looking at the servers
SystemOut.log or trace.log. If the excessive time is due to the request simply taking a long time
to complete on the server, you need to increase the readTimeout value in the HTTP transport
PolicySet.

Summary
In this article, you learned some basic problem determination techniques you can use with the
Feature Pack for Web Services. In addition, you learned about some typical error conditions and
some possible solutions to those errors. This article can help you quickly recognize and diagnose
problems that you encounter while developing, deploying, and executing your JAX-WS Web
service applications using the Feature Pack for Web Services.

Related topic WebSphere Application Server 6.1.0 documentation

Troubleshooting JAX-WS applications with the WebSphere Page 11 of 12


Application Server V6.1 Feature Pack for Web Services
developerWorks ibm.com/developerWorks/

About the author


Phil Adams

Phil Adams is a senior software engineer in the IBM Software Group. For the last 9
of his 23 years with IBM, he has been a part of the WebSphere development team.
For the past 6 years he has focused on web services, starting with the JAX-RPC
web services engine. Phil was responsible for the design and implementation of
the SOAP/JMS support introduced in the WebSphere Application Server 5.0.2
release, and has been involved in designing and implementing various enhancements
to the SOAP/JMS support since then. Phil is now a member of the W3C SOAP/
JMS Working Group, whose mission is to produce a SOAP/JMS interoperability
specification

Copyright IBM Corporation 2008


(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)

Troubleshooting JAX-WS applications with the WebSphere Page 12 of 12


Application Server V6.1 Feature Pack for Web Services

You might also like