This document covers the logging facility and the utility for monitoring of SOAP messages.
The information is organized under the following headings.
This section provides details on the SOAP monitoring utility in Web Services Stack.
The information is organized under the following headings:
The distribution of Web Services Stack comes with a SOAP monitor that allows users to monitor SOAP messages exchanged between Web service clients and Web services running in Web Services Stack.
SOAP messages are shown with the structure that they have after they have passed all system phases in the Axis 2 engine. This means that the original SOAP messages, sent by a user, can be visually different, but semantically equal to the ones shown into the SOAP monitor. Examples of such a case are MTOM SOAP messages. SOAP monitor shows the binary data exchanged “by value” (included into the SOAP message itself). On the other hand, the original SOAP message has MIME parts in it.
For example, take a binary data shown into a TCPMon (general purpose tcp monitor). To make easy to understand, only part of the message related to the MTOM-ized binary data is shown:
<ns1:binaryData><xop:Include href="cid:1.urn:uuid:EFF202258F699D83131220514272228@apache.org" xmlns:xop="http://www.w3.org/2004/08/xop/include" /></ns1:binaryData> … --MIMEBoundaryurn_uuid_EFF202258F699D83131220514272117 Content-Type: text/plain Content-Transfer-Encoding: binary Content-ID: <1.urn:uuid:EFF202258F699D83131220514272228@apache.org> text --MIMEBoundaryurn_uuid_EFF202258F699D83131220514272117—
The binary data that a SOAP monitor shows is the following:
<ns1:binaryData>dGV4dA==</ns1:binaryData>
As you can see, the binary data is shown “by value”. This is because it was already processed by the system phases of the Axis 2 engine.
SOAP monitor is disabled by default.
To enable SOAP monitor
Open the web.xml file that is located in the WEB-INF directory of the wsstack webapp.
Uncomment the
<servlet-name>SOAPMonitorService</servlet-name>
part.
Uncomment the <servlet-mapping> part.
Copy the following SOAPMonitor classes from
soapmonitor folder and paste them directly under the
expanded wsstack context root:
org\apache\axis2\soapmonitor\applet\SOAPMonitorApplet$ServiceFilterPanel.class org\apache\axis2\soapmonitor\applet\SOAPMonitorApplet$SOAPMonitorData.class org\apache\axis2\soapmonitor\applet\SOAPMonitorApplet$SOAPMonitorFilter.class org\apache\axis2\soapmonitor\applet\SOAPMonitorApplet$SOAPMonitorPage.class org\apache\axis2\soapmonitor\applet\SOAPMonitorApplet$SOAPMonitorTableModel.class org\apache\axis2\soapmonitor\applet\SOAPMonitorApplet$SOAPMonitorTextArea.class org\apache\axis2\soapmonitor\applet\SOAPMonitorApplet.class
Important:
Ensure you keep the classes packaging structure.
Engage the soapmonitor Axis 2 module globally in the axis2.xml by adding the following line:
<module ref="soapmonitor"/>
You can engage it in the same way for a service in the services.xml file.
Restart Tomcat or the wsstack webapp.
Go to http://<host>:<port>/wsstack/SOAPMonitor to start using the SOAP monitor.
For more details on the SOAP monitor configuration, see http://axis.apache.org/axis2/java/core/docs/soapmonitor-module.html.
SOAP monitor is disabled by default.
To enable SOAP monitor
Open the axis2.xml file that is located in the <Software AG_directory>\profiles\CTP\workspace\wsstack\repository\conf directory.
Engage the soapmonitor Axis2 module globally in the axis2.xml by adding the following line:
<module ref="soapmonitor"/>
You can engage it the same way for a service in the services.xml file.
Add a soapMonitorPort parameter which defines
the port to use for communication with the SOAP Monitor Applet
<parameter name="soapMonitorPort">5001</parameter>
Note:
If the port parameter is missing or empty, the SOAP Monitor
servlet will not be available.
Restart the Platform Tomcat Server.
Go to http://<host>:<port>/wsstack/SOAPMonitor to start using the SOAP monitor.
For more details on the SOAP monitor configuration, see http://axis.apache.org/axis2/java/core/docs/soapmonitor-module.html.
This section provides details on the logging facility in Web Services Stack web application.
The information is organized under the following headings:
Web Services Stack uses Apache Commons Logging (JCL) and its
log4J facility. The JCL provides thin-wrapper log
implementations for other logging tools, including the default
log4J.
For details on log4J, refer to Apache logging
services at
http://logging.apache.org/log4j/1.2/index.html.
Note:
The distribution of Web Services Stack comes with a log4j.properties file and a commons-logging.properties file by default. You can find them in <Web Services Stack_Install_directory>/webapp/wsstack/WEB-INF/classes.
Note:
Those files are also included in the
wsstack.war web archive in <Web Services
Stack_Install_directory>/webapp, in case you deploy Web Services
Stack another servlet container or application server.
To enable log4J
Place the commons-logging.properties file into the given module classpath.
The log4j.properties files come with a default value of the logging level. You can change those values according to the requirements of your system.
The default logging level is info.
Following are the standard levels in descending (in terms of priority)
order:
fatal
error
warn
info
debug
trace
Note:
A lower level covers all levels above it. For example, if
warn is set, then all logs of level
error and fatal are
logged, too.
It is important to ensure that the log messages are appropriate in content and severity. See the following table for guidelines on the usage of logging levels:
| Logging Level | Usage |
|---|---|
| fatal |
Severe errors that cause premature termination. Expect these to be immediately visible on a status console. |
| error |
Other runtime errors or unexpected conditions. Expect these to be immediately visible on a status console. |
| warn |
Use of deprecated APIs, poor use of API, error-like situations, other runtime situations that are undesirable or unexpected, but not necessarily incorrect. Expect these to be immediately visible on a status console. |
| info |
Interesting runtime events (start /shut down). Expect these to be immediately visible on a console, so be conservative and keep to a minimum. |
| debug |
Detailed information on the flow through the system. Expect these to be written to logs only. |
| trace |
More detailed information. Expect these to be written to logs only. |
This section provides details on the logging facility in Web Services Stack on Platform Tomcat Server Server.
The information is organized under the following headings:
Web Services Stack running on the Platform Tomcat Server uses Journal
Logging as a logging mechanism. The Journal Logging is delivered with the
following shared component bundle:
com.softwareag.sc.core and its configuration file is
located in the following directory on the file system:
<Software
AG_directory>/profiles/<profile>/configuration/logging/log_config.xml
Basically, the format of the log_config.xml file is the same as the format of the Log4J XML configuration. Apart from that, the Journal Logger contains several additional appenders than the standard Log4J appenders.
To enable logging and configure the corresponding severity, edit the log_config.xml file and edit the following excerpt as shown in the sample below:
<root>
<level value="info" />
<appender-ref ref="Platform.Console" />
<appender-ref ref="Platform.RollingLogFile" />
</root>
The Journal Logger is a wrapper around Log4J and every Journal Logging (JL) logger wraps a standard Log4J logger. For this reason the JL component delivers Log4J as part of its implementation. The JL configuration is a standard Log4J configuration that sets up the underlying Log4J library. If you need you can use Log4J directly. You should add your Log4J settings to the JL configuration file.
The default logging level is info.
Following are the standard levels in descending order (in terms of
priority):
fatal
error
warn
info
debug
trace
Note:
A lower level covers all levels above it. For example, if
warn is set, then all logs of level
error and fatal are
logged, as well.
It is important to ensure that the log messages are appropriate in content and severity. See the following table for guidelines on the usage of logging levels:
| Logging Level | Usage |
|---|---|
| fatal |
Severe errors that cause premature termination. Expect these to be immediately visible on a status console. |
| error |
Other runtime errors or unexpected conditions. Expect these to be immediately visible on a status console. |
| warn |
Use of deprecated APIs, poor use of API, error-like situations, other runtime situations that are undesirable or unexpected, but not necessarily incorrect. Expect these to be immediately visible on a status console. |
| info |
Interesting runtime events (start /shut down). Expect these to be immediately visible on a console, so be conservative and keep to a minimum. |
| debug |
Detailed information on the flow through the system. Expect these to be written to logs only. |
| trace |
More detailed information. Expect these to be written to logs only. |
Web Services Stack provides a logging mechanism for its agent programs that use the System Management Hub administration functionality. These agent programs are called System Management Hub agents. They manipulate the Web Services Stack environment under the System Management Hub web interface. For more information, see Administration Tool for details.
If you experience problems when using the administration tool, you must enable the logging for the System Management Hub agents to see a detailed message log. It is recommended to use this logging mechanism only when you want to search for faults in the operation of the system. Otherwise, the performance of your interface may decrease.
To enable logging on System Management Hub agents
Start the web interface of System Management Hub in a web browser.
To open the registry editor, navigate to:
> > > > > > > > > > .
Right click the node.
On the menu that opens, click .
Switch the value of the registry parameter
enableLog to "1".
Click .
You can find the output log file in <Software AG_directory>/WS-Stack/argus/wsstack.log.