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:

• To debug axis2 soap request / response messages effectively, add the following as JVM Arguments in eclipse (for axis2 java clients) or pass this in websphere console JVM Process definition VM Arguments. or as JAVA_OPTS for weblogic, and it requires a server restart if applied in application server. Please use this only for debugging purpose.

  -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.SimpleLog 
  -Dorg.apache.commons.logging.simplelog.showdatetime=true 
  -Dorg.apache.commons.logging.simplelog.log.httpclient.wire=debug 
  -Dorg.apache.commons.logging.simplelog.log.org.apache.commons.httpclient=debug

  This java system property will enable console logging of the soap request sent and soap response received. this is another alternative to using soap monitor.
• 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.