Java logging

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: 這個主題參照一或多個應用程式伺服器日誌檔。 此外,在分散式和 IBM® i 系統上,另外也建議您可以配置伺服器來使用「高效能可延伸記載 (HPEL)」日誌和追蹤基礎架構,而不使用 SystemOut.logSystemErr.log, trace.logactivity.log 檔案。HPEL 與原生 z/OS® 記載機能也可以一起使用。如果您使用 HPEL,則可以從伺服器設定檔 bin 目錄,利用 LogViewer 指令行工具來存取您所有的日誌和追蹤資訊。請參閱有關利用 HPEL 疑難排解應用程式的資訊,以取得更多使用 HPEL 的相關資訊。
[z/OS]Note: The SystemOut.log and STDOUT streams are redirected to the SYSPRINT ddname under z/OS. The SystemErr.log 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.

指出主題類型的圖示 概念主題



時間戳記圖示 前次更新: July 9, 2016 11:11
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=ctrb_javalogging
檔名:ctrb_javalogging.html