Java logging is the logging toolkit that is provided by the java.util.logging
package. Java logging provides a standard logging API for your applications.
Message logging (messages) and diagnostic trace (trace) are conceptually
similar, but do have important differences. These differences are important
for application developers to understand to use these tools properly. The
following operational definitions of messages and trace are provided.
- Message
- A message entry is an informational record that is intended for end users,
systems administrators, and support personnel to view. The text of the message
must be clear, concise, and interpretable by an end user. Messages are typically
localized and displayed in the national language of the end user. Although
the destination and lifetime of messages might be configurable, enable some
level of message logging in normal system operation. Use message logging judiciously
because of performance considerations and the size of the message repository.
- Trace
- A trace entry is an information record that is intended for service engineers
or developers to use. As such, a trace record might be considerably more complex,
verbose, and detailed than a message entry. Localization support is typically
not used for trace entries. Trace entries can be fairly inscrutable, understandable
only by the appropriate developer or service personnel. It is assumed that
trace entries are not written during normal runtime operation, but can be
enabled as needed to gather diagnostic information.
The application server redirects the system streams at the server startup.
There is no way to allow the application to output logging to the console
because the system streams can not be obtained by the application. If you
would like to use console to monitor the application without using the console
handler, you can either monitor the SystemOut.log file, or monitor
a file created by another file handler.
Note: The application server uses Java logging internally and therefore certain
restrictions apply for using system streams with this logging API by applications.
During server startup, the standard output and error streams are replaced
with special streams that write to the logging infrastructure, in order to
include the output of the system streams in the log files. Because of this,
applications can not use
java.util.logging.ConsoleHandler, or any
handler writing to
System.err or
System.out streams, attached
to the root logger. If the user does attach the handler to the root logger,
an infinite loop is created within the logging infrastructure, leading to
stack overflow and server crash.
If the use of a handler that writes to
system streams is necessary, attach it to a non-root logger so that it does
not publish log records to parent handlers. The data written to the system
streams is then formatted and written to the corresponding system stream log
file. To monitor what is being written system streams, the configured log
files (SystemOut.log and SystemErr.log by default) can be
monitored.
Note: The System.out and STDOUT streams are
redirected to the SYSPRINT ddname under z/OS. The System.err and STDERR streams
are redirected to the SYSOUT ddname under z/OS. By default, the WebSphere
Application Server for z/OS cataloged procedures associate these ddnames with
print (SYSOUT=*) data sets, causing message logs to go into WebSphere Application
Server job output. Job output can be viewed with the Spool Display and Search
Facility (SDSF) or equivalent software.