Tools and Techniques for Troubleshooting Axis2 and Axis 1.4 Errors

The following highlight possible tools and techniques you might use in troubleshooting errors with Axis2 or Axis 1.4 web services, but is not an exhaustive list. Also, the tools available to you may vary by platform and application server environment.

When trying to understand why a service has failed the following should be considered:

Use a monitoring tool (e.g. Apache TCPMon or SOAP Monitor) to view the SOAP message traffic. It's easier to setup TCPMon (download from http://ws.apache.org/commons/tcpmon, unzip, & run; also available within soapUI), but it requires changing your client end points or your server port. Once setup, SOAP Monitor doesn't require any client or server changes, but does require special build steps for your WAR/EAR files. Apache ships SOAP Monitor as an Axis2 module and see Including the Axis2 SOAP Monitor in Your Web Services WAR File on how to include this in your built Axis2 environment.

Look at the failure stack trace and investigate any messages there. Try to understand where in the processing the error occurred. Here is an example Apache log4j properties file that would log verbosely in a C:\Temp\axis2.log file, you can adjust these settings to suit your requirements.

# Set root category
log4j.rootCategory=DEBUG, CONSOLE, LOGFILE

# Set the enterprise logger priority to FATAL
log4j.logger.org.apache.axis2.enterprise=FATAL
log4j.logger.de.hunsicker.jalopy.io=FATAL
log4j.logger.httpclient.wire.header=FATAL
log4j.logger.org.apache.commons.httpclient=FATAL

# CONSOLE is set to be a ConsoleAppender using a PatternLayout.
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=[%p] %m%n

# LOGFILE is set to be a File appender using a PatternLayout.
log4j.appender.LOGFILE=org.apache.log4j.FileAppender
log4j.appender.LOGFILE.File=c:/temp/axis2.log
log4j.appender.LOGFILE.Append=true
log4j.appender.LOGFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.LOGFILE.layout.ConversionPattern=
  %d [%t] %-5p %c %x - %m%n

You need to place the log4j.properties somewhere in the classpath of the Axis2 or Axis 1.4 WAR file.

Check the application server logs for more information.
Turn on log4j tracing for Axis2 or Axis 1.4 as this will most likely give you the most detailed picture of the web service processing or error at the time of the failure. This can be quite voluminous so use it with care.
Turn on the IBM Cúram Social Program Management application log4j trace as this will also help to give you further context for the failure.
Consider remote debugging the service running on the application server using Eclipse. Consult your application server-specific documentation for setting up this kind of an environment. Remember that if you are setting breakpoints in this kind of environment that timeouts in the client and/or server are a high probability and appropriate steps should be taken; for the client see Creating a Client and Invoking the Web Service and for the server consult your application server-specific documentation for setting timer values.

Note: Application verbose tracing (trace_verbose) is the highest level of logging available for tracing with web services. This is because the SDEJ employs a proxy wrapper object for ultra verbose (trace_ultra_verbose) tracing in order to provide detailed logging. Due to the fact that the SDEJ uses reflection for forwarding a web service request to the underlying process class, the use of a proxy wrapper object is not compatible with the web services infrastructure.