1, Commons-Loggin Introduction Jakarta Commons Logging (JCL) provides a log (INTERFACE), while taking into account lightweight and independent log implementation tools. It provides a simple log operation to the middleware / log tool developer, allowing program developers to implement tools using different specific logs. Users are assumed to be familiar with a higher level of detail of a log implementation tool. The interface provided by JCL, which has simple packages for other log tools, including log4j, avalon logkit, and jdk 1.4, etc., which are closer to log4j and logkit implementations. 2. Quick Start JCL has two basic abstractions Class: Log (Basic Recorder) and LogFactory (responsible for creating a log instance). When commons-logging.jar is added to ClassPath, it will rationally guess your favorite log tool, then make self-settings, users do not need to do any settings at all. The default logfactory is discovered by the following steps and decides that the log tool will be used (in order, the search process will abort when the first tool is found):
Looking for the value of the current factory called org.apache.commons.logging.log Configuration Property Value Logging Org.Apache.commons.logging.log value if the application's ClassPath is used, use related Wrapper class (log4jlogger) If the application runs in a system of JDK1.4, use the related packaging class (JDK14Logger) using the simple log package class (SimpleLog)
3, develop using logging // in the program file header Import related class import org.apache.commons.logging.log; import org.apache.commons.logging.logfactory; ... // Get in the class An instance public class myclass {private static log log = logfactory.getlog (myclass.class); ...} The log information is sent to the logger, such as the LOG in the above example. This transmission process is done by calling the method defined in the log interface. Different methods are associated with different levels, and the log information is sent which level method is transmitted, and the level of the log information is indicated. Org.apache.commons.logging.logging The method defined in the interface is:
Log.fatal (Object Message); log.fatal (Object Message, throwable T); log.error (Object Message); log.error (Object Message, throwable T); log.warn (Object Message); log.warn Object message, Throwable t); log.info (Object message); log.info (Object message, Throwable t); log.debug (Object message); log.debug (Object message, Throwable t); log.trace (Object Message); Log.Trace (Object Message, Throwable T);
In addition, the following methods are provided for code protection.
Log.isfatalenabled (); log.iserrorenabled (); log.iswarnenabled (); log.isinfoenabled (); log.IndebugeNabled (); log.Istracenabled ();
The level of information ensures proper extent of log information in the severity of content and response issues. Fatal is very serious and causes the system to abort. It is expected that such information can be displayed immediately on the status console. Error Other runtime errors or is not expected. It is expected that such information can be displayed immediately on the status console. Warn uses the API that does not agree with the use of the API, which is very bad, 'is almost' errors, other runtime do not need the need and the expected state, but it is not necessary to be called "error". It is expected that such information can be displayed immediately on the status console. The meaningful events generated by INFO run. It is expected that such information can be displayed immediately on the status console. Detail information in the DEBUG system process. It is expected that such information is only written to the log file. TRACE is more detail. It is expected that such information is only written to the log file.
Normally, the level of the recorder should not be lower than INFO. That is to say, usually the information of DEBUG should not be written in the log file.
Lifecycle JCL logFactory must implement a connection to establish / disconnect to log tools, instantiate / initialize / deconstruct a log tool. An exception handling JCL log interface does not specify any exception handling, and the implementation of the interface must capture and process an exception. Multi-threaded JCL LOG and LOGFACTORY implementation must ensure that any log tools are required for parallelism.
Log4j uses the print format of the Printf function in a C language, and the print parameters are as follows:
The message% P output priority specified in the% M output code, namely Debug, INFO, WARN, ERROR, FATAL% R Output self-application start to output the LOG information consuming millisecond% C output belongs, usually The full name% T output of the class is generated to generate the log event, the Windows platform is "/ r / n", the Unix platform is "/ n"% D output log time point or time The default format is ISO8601, or it can be specified in the format, such as:% D {YYY MMM DD HH: MM: SS, SSS}, Output: October 18, 2002 22: 10: 28, 921% l Output The occurrence position of the log event, including the category name, the thread that occurs, and the number of rows in the code. Example: Testlog4.main (Testlog4.java: 10)
