WSIF troubleshooting tips
For information on resolving WebSphere-level problems, see Diagnosing and fixing problems.
To identify and resolve WSIF-related problems, you can use the standard WAS trace and logging facilities. If you encounter a problem that you think might be related to WSIF, you can check for error messages in the WAS administrative console, and in the appserver's stdout.log file. One can also enable the application server debug trace to provide a detailed exception dump.
A list of the WSIF runtime system messages, with details of what each message means, is given in Message reference for WSIF.
Here is a checklist of major WSIF activities, with advice on common problems associated with each activity:
- Handcrafted WSDL can cause numerous problems. To help ensure that your WSDL is valid, use a tool such as WebSphere Studio Application Developer (WSAD) to create your service.
Define transport mechanism
- For JMS, check that you have set up JNDI correctly, and created all the necessary queues.
- For SOAP, make sure that the deployment descriptor (dds.xml) is correct - preferably by creating it using WSAD or similar tooling.
Create client - Java code
- Follow the correct format for creating a WSIF service, port, operation and message. For examples of correct code, see the Address Book sample.
Compile code (client and service)
- Check that the build path against code is correct, and that it contains the correct levels of JAR files.
- Create a valid EAR file for your service in preparation for deployment to a web server.
- When you install and deploy the service EAR file, check carefully any messages given when the service is deployed.
Server setup and start
- Make sure that the WAS file server.policy (in the /properties directory) has the correct security settings within it. For more information see Enabling security for WSIF.
- Check that file wsif.properties is correctly set up. For more information see Maintaining the WSIF properties file.
- Either check that you have defined the class path correctly to include references to your client classes, WSIF JAR files and any other necessary JARs, or (preferably) run your client using the WAS launchClient tool.
Here is a list of common errors, and information on their probable causes:
"No class definition" errors received when running client code
- This is likely to be a problem with the class path setup. Check that the relevant JAR files are included.
"Can't find WSDL" error
Some likely causes are:
- The appserver is not running.
- The server location and port number in the WSDL are not correct.
- The WSDL is badly formed (check the error messages in the application server's stdout.log file).
- The appserver has not been restarted since the service was installed.
You might also try the following checks:
- Can you load the WSDL into your Web browser from the location specified in the error message?
- Can you load the corresponding WSDL binding files into your Web browser?
Your Web service's EAR file does not install correctly onto the appserver.
- It is likely that the EAR file is badly formed. Verify the installation by completing the following steps:
- For an EJB binding, run the WAS tool dumpnamespace. This tool lists the current contents of the JNDI directory.
- For a SOAP over HTTP binding, open http://pathToServer/WebServiceName/admin/list.jsp (if you have the SOAP administration pages installed). This page lists all currently installed Web services.
- For a SOAP over JMS binding, complete the following checks:
There is a permissions problem or security error.
- Check that the WAS file server.policy (in the /properties directory) has the correct security settings within it. For more information see Enabling security for WSIF.
Using WSIF with multiple clients causes a SOAP parsing error.
- Before you deploy a Web service to WAS, decide on the Web service's scope. The application's deployment descriptor file (dds.xml) includes the following line:
<isd:provider type="java" scope="Application" ......
One can set Scope to "Application" or "Session". The default setting is "Application", and this is correct if each request to the Web service does not require objects to be maintained for longer than a single instance. If Scope is set to "Application" the objects are not available to another request during the execution of the single instance, and they are released on completion. If your Web service needs objects to be maintained for multiple requests, and to be unique within each request, set the scope to "Session". If Scope is set to "Session", the objects are not available to another request during the life of the session, and they are released on completion of the session. If scope is set to "Application" but it should be set to "Session", you might get the following SOAP error:
SOAPException: SOAP-ENV:ClientParsing error, response was: FWK005 parse may not be called while parsing.; nested exception is: [SOAPException: faultCode=SOAP-ENV:Client; msg=Parsing error, response was: FWK005 parse may not be called while parsing.; targetException=org.xml.sax.SAXException: FWK005 parse may not be called while parsing.]
WSIF system management and administration
Maintaining the WSIF properties file
Enabling security for WSIF
Trace and logging for WSIF
WSIF (Web Services Invocation Framework) messages
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.