You can handle logging and tracing configurations by enabling tracing at server
start up, enabling tracing on a WebSphere Commerce instance, or enabling logging on the WebSphere Commerce client library on a stand-alone program.
You can now configure
independent log levels for classes and packages.
Note: When you work with IBM to debug request
processing problems, there might be occasions where low-level tracing components must be enabled to
capture details for how the request is processed. These low-level Application server trace
components do not know the request intent or the potential data within. Therefore, when enabled, it
is possible that these tracing components might potentially include sensitive information, in plain
text, in the trace file.
It is recommended that you do not enable these types of tracing
components on a production system and attempt to simulate the problem on a quality assurance
environment to capture the appropriate information. However, if the tracing components must be
enabled on a production system, handle the trace files with caution. Before you send the trace,
remove sensitive data that might be in the trace before you allow a third party to use the trace for
diagnosis. Further, when the trace is no longer required, remove the files with a military-grade
data wiping process. When the problem is found and the tracing component is no longer required,
immediately disable the low-level tracing components.
Procedure
-
Enable tracing in WebSphere Commerce. These steps are duplicated from theWebSphere Application Server documentation. For more information, see the Working with trace
group of topics in the WebSphere Application Server documentation.
-
Open the WebSphere Application Server Administrator's Console. To do so within Rational Application
Developer, right-click the WebSphere Commerce Test Server and select .
-
Expand . The Logging and Tracing page displays in the workspace on the
right.
-
Click the server for which you want to enable the tracing (such as 'server1'). The window
refreshes to display the logging and tracing options for the server.
-
Click Diagnostic Trace. The Diagnostic Trace
Service window displays in the workspace.
-
Click the Configuration or Runtime tab.
Changes made to Configuration are stored on the file system and applied
when the server starts. You must restart the server to pick up any changes. This is required for
finding issues that originate or occur when the server is initiated. Modifications to
Runtime are applied immediately and are lost after the server is
restarted.
- Optional:
Select Change Log Detail Levels to modify tracing configurations for
components or packages.
If you are tracing multiple log detail levels, separate the traces with a colon. For
example:
com.ibm.websphere.commerce.WC_SERVER=all:
com.ibm.websphere.commerce.WC_ORDER=all
Tracking all
helps in diagnosing problems so that multiple traces can be
avoided. As an alternative to all
, classes can also use warning
and info
traces, where info
contains the least trace impact.
For more information about enabling tracing for the correct components and configuring the proper
trace settings for your environment, see:
-
Click to apply the changes to your server. If you selected to change the log details levels
on the Configuration tab, restart your server.
-
Enabling logging on the WebSphere Commerce client library on a stand-alone program
You can debug problems when a stand-alone Java program has issues with the WebSphere Commerce client library by enabling logging.
The foundation logging helper,
com.ibm.commerce.foundation.common.util.logging.LoggingHelper
, is used to obtain
logging objects. This class has helper methods that determine whether tracing and entry and exit
tracing is enabled. Logging properties are overridden with a separate logging properties
file.
-
Navigate to a directory of your choice and create a new file called
logging.properties.
-
Paste the following contents into the logging.properties file:
#------------------------------------------
# Handlers
#-----------------------------------------
handlers=java.util.logging.ConsoleHandler,java.util.logging.FileHandler
# Default global logging level
.level=ALL
# ConsoleHandler
java.util.logging.ConsoleHandler.level=OFF
java.util.logging.ConsoleHandler.formatter=java.util.logging.SimpleFormatter
# FileHandler
java.util.logging.FileHandler.level=FINE
# Naming style for the output file:
java.util.logging.FileHandler.pattern=logs/loadData.log
# Name of the character set encoding to use
java.util.logging.FileHandler.encoding=UTF8
# Limiting size of output file in bytes:
java.util.logging.FileHandler.limit=25000000
# Number of output files to cycle through
java.util.logging.FileHandler.count=2
# Style of output (Simple or XML):
java.util.logging.FileHandler.formatter=java.util.logging.SimpleFormatter
Default properties:
Property |
Value |
Logging level |
FINE |
Encoding |
UTF8 |
Log file size limit |
25MB |
Log file scrolling |
2 |
-
Restart your application, specifying the following generic JVM arguments in theWebSphere Application Server Administrator's Console.
For example, :
-Djava.util.logging.config.file="file_path/logging.properties"
Include
the following path into the class path of the Java
application:
file_path/logging.properties
Where
file_path is the directory of your choice, created in the first
step.