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
SystemErr.log 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: This topic references one or more of the application
server log files. As a recommended alternative, you can configure
the server to use the High Performance Extensible Logging (HPEL) log
and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM® i systems. You can also use
HPEL in conjunction with your native z/OS® logging facilities. If you are using HPEL, you can access
all of your log and trace information using the LogViewer command-line
tool from your server profile bin directory. See the information
about using HPEL to troubleshoot applications for more information
on using HPEL.