Package com.sap.tc.logging

Provides the classes for emitting and controlling the output of trace and log messages, and the classes for organizing hierarchies of message kinds, origins and destinations.

See:
Description

Interface Summary

CreateLogfileListener	Listen to the create logfile event.
Event	General Event from logging
EventDispatcher	Manage the general event notification mechanism
EventListener	General listener to an event from logging
Filter	Provides, in addition to effective severities, control of writing log records to logs or log controllers.
LogEvents
LoggingResultSet	General result set for objects used in Logging.
MessageEventListener	Listen to the message being written.
NewLogListener	Listen to the log adding event.
OverwriteLogfileListener	Listen to the logfile being overwritten event.
ReleaseLogListener	Listen to the logfile being overwritten event.
RemoveLogListener	Listen to the log removal event.
ResetLogControllerListener	Listen to the LogController reset event.

Class Summary

APILogger
BaseLog
Category	Describes messages specific to distinguished problem areas and is above all used to emit log messages.
Configurator	Configures the Logging API according to its settings.
ConsoleLog	Writes log records to System.err.
CreateLogfileEvent	This event will be fired when an existing logfile is being cleaned up and overwritten with new messages. This can happen when: When a filelog has been defined with rotating feature, and existing file in the rotating sequence is overwritten by the continuous growth of messages.
EventDispatcherFactory	This factory manages the event dispatcher of the logging tool.
ExceptionHandling
ExceptionManager
FileLog	Writes log records to files.
FileLogInfoData
FileLogSet
Formatter	Formats log records on behalf of logs the formatter is registered with.
FormatterType	Defines and provides typesafe enums of types of Formatter used in logging to format a log message and its related information.
Group
GUId
HelperLib
ListFormatter	Formats log records as simple hash-separated columns.
Location	Describes messages that originate from delimited source code areas and is above all used to emit trace messages.
Log	Writes log records to destinations.
LogController	Controls output to logs, which stand for destinations to write log messages to.
LoggingManager
LogInfoData
LogRecord	Internal form of log messages.
MessageEvent	This event will be fired when an message is being processed.
MSGCollection
MsgType	Collects constants for internal use as message format types as well as some static utility methods.
NewLogEvent	An event indicating a log is ready to be used to output logging messages.
OverwriteLogfileEvent	This event will be fired when an existing logfile is being cleaned up and overwritten with new messages. This can happen when: When a filelog has been defined with rotating feature, and existing file in the rotating sequence is overwritten by the continuous growth of messages.
PropertiesConfigurator	Configures the Logging API according to a set of properties.
ReleaseLogEvent	This event will be fired before an existing logfile is being cleaned up and overwritten with new messages, before OwerwriteLogfileEvent. This can happen when: When a filelog has been defined with rotating feature, and existing file in the rotating sequence is overwritten by the continuous growth of messages.
RemoveLogEvent	An event indicating a log is no longer in use to output logging messages.
Severity	Collects constants for use as severities as well as some static utility methods.
StreamLog	Writes log records to output streams.
TokenType
TraceFormatter	Formats log records as readable lines.
UID	The UID class
Version	Logging API Version
XMLFormatter	Formats log records as XML elements.

Exception Summary

UnsupportedFormatException

Deprecated. Use the com.sap.tc.logging.exception.UnsupportedFormatException class

Package com.sap.tc.logging Description

Provides the classes for emitting and controlling the output of trace and log messages, and the classes for organizing hierarchies of message kinds, origins and destinations.

There are two different classes for emitting messages to, Location and Category, both of which are derived from the base class LogController. Locations describe messages that originate from delimited source code areas, such as components, packages, classes and methods. This is typical of traces, and hence messages emitted to locations are classical trace messages. Therefore, if you are above all interested in writing traces, please take a look at the introduction to this class first. Categories describe messages specific to distinguished problem areas, such as databases, networking, security auditing and others. This is typical of logs, and hence messages emitted to categories are classical log messages.

Both kinds of log controllers control writing of messages, in addition to message severities, via filters which must implement the interface Filter. Log controllers are automatically ordered into hierarchies, and severities and filters are among the properties that are passed on from parents to children unless overridden.

Besides locations being proxies for traces and categories being proxies for logs, locations can also be used to describe the origin of log messages and, vice versa, categories to describe the nature of trace messages. This is used to take advantage of synergistic effects. For example, log messages that come from a given source code area can be emitted to both the responsible category and the corresponding location at the same time with a single method call. The messages in both the resulting log and trace sport the same identification which makes it much easier to find those trace messages that show the circumstances of particular problems described in log messages. It is also possible to set severities of controllers in relation to other controllers. This allows the enabling of logs for specific locations, for example packages or classes, or, vice versa, using categories to classify trace messages and enable writing messages of specific categories without affecting the outcome of other trace calls. It also lets us get rid of the need for custom severities.

Log controllers themselves write messages to instances of various subclasses of Log. Whereas these instances stand for different destinations, subclasses provide access to different kinds of destinations such as files or sockets. Logs format messages using instances of Formatter.

A few words on fault tolerance: the usual mechanism for error handling in Java is throwing exceptions. However, in case of a component for logging and tracing, which among other things deals with locating errors and problems, throwing exceptions means creating a vicious circle. This matter is dealt with as follows. First of all, in general methods do not throw exceptions but instead make them available via other methods of the object at hand, called getException() and throwException(), which return, or throw, a potential exception from the preceeding normal call. This is true in particular of runtime exceptions such as java.lang.NullPointerException. However, care has to be taken because exceptions are not reset. To make sure that an exception had actually been caused by a call, either reset the exception store before the call with resetException() or compare the results of getException() before and after it. In addition to storing exceptions, methods themselves log problems to the dedicated category /System/Logging, except for calls emitting messages where this would generate too much output. In both cases, however, care has been taken for the implementation to act as meaningful as possible even in the face of errors. A notable deviation from the above are methods that are meant to be called in static field declarations and initializers. In most of these cases, exceptions lead to immediate program termination upon loading a class. It is therefore improbable for them to pass unnoticed until after distributing the software.