General Rules for Using Logs and Traces in J2EE Engine 

Who uses logs and traces?

●      Logging – Administrators and wide customers are interested in log files to view messages specific to distinguish problem areas. Therefore, logs are always switched on and get written automatically. They have predefined granularity (severity) that can be modified during runtime.

●      Tracing – Support engineers and developers use the trace files facility to check an abnormal condition in the control flow. Therefore, tracing is not normally turned on. Traces can be switched on if a problem has occurred and a detailed analysis of a distinct part of a program is necessary.

How to control the log output?

To control the log output you need a log controller. It is an object you call to write log and trace messages. Two types of log controllers are available:

●      Category – describes messages specific to distinguished problem areas. It is used to emit log messages. Typical problem areas are: databases, networking, security auditing, and others.

●      Location – describes messages that originate from delimited source code areas. It is used to emit trace messages. Locations refer to certain points in the coding and can be identified with package-, class-, or function- names.

Where the log and trace messages are written?

Log and trace messages are written in destinations. Destinations are predefined by the SAP Logging API. For more information, see Log (Destination).

In which format does each destination type print the log and trace messages?

Each log destination type can print messages in certain formats, using the following log formatters: TraceFormatter, XMLFormatter, and ListFormatter. For more information , see Formatter.

Levels of Severity

An important part of any log and trace message is its severity. This denotes the level of importance or relevance of a certain message. Logs and traces can be limited to certain severity levels, that is, only data of a defined severity is collected. The increasing order of the severity levels is:

●      DEBUG – For debugging purpose, with extensive and low level information.

●      PATH – For tracing the execution flow.

●      INFO – Informational text, mostly for echoing what has already been performed.

●      WARNING – The application can recover from an anomaly and fulfill the required task, but needs attention from a developer/system operator.

●      ERROR – The application can recover from an error, but it cannot fulfill the required task due to the error.

●      FATAL – The application cannot recover from an error, and the severe situation causes fatal termination.

Using logs and traces

During normal operation, developers and support engineers are not looking at a running system, unlike administrators who have to check the system regularly. This implies that traces do not have to be shown during normal operation, but logs do.

When you write log and trace messages, consider the following:

●      Write to logs only those messages that are important for an administrator who supervises the system during normal operation. Write to traces everything that might be important for tracing erroneous behavior.

●      Messages with severity DEBUG and PATH must be written as traces only. They must not be written as log messages.

●      Any error message (with severity ERROR or FATAL) has to be written as a log message. They must not be written as trace messages.