Troubleshooting JAX-WS applications with the WebSphere Application Server V6.1 Feature Pack for Web Services

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.

Share:

Phil Adams (phil_adams@us.ibm.com), Senior Software Engineer, IBM

Phil Adams photoPhil 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



02 April 2008

Introduction

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. We’ll 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

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 (see Resources), 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.*=allPolicyset component
com.ibm.ws.wssecurity.*=allWS-Security component
com.ibm.ws.wsaddressing.*=all WS-Addressing component
com.ibm.ws.wstx.*=allWS-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
    Figure 1. Use the administrative console to set the trace string for an application server
  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
    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 server’s 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, 
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:
[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 you’ll 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/">
<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 
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 endpoint’s 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 module’s 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.

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 server’s 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.

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)

Solution: This type of error normally indicates that the async response servlet application (ibmasyncrsp.ear) was not properly installed, which implies that the Application Server’s 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:

[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 server’s 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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services
ArticleID=298452
ArticleTitle=Troubleshooting JAX-WS applications with the WebSphere Application Server V6.1 Feature Pack for Web Services
publish-date=04022008