To tell you the truth, JCL (Jakarta Commons Logging) and log4j really got me. Not all do log, how in the JCL source package, there is a log4j package. Who's with whom? To see the JCL User's guide, to understand some. Hehe.
1, Commons-loggin introduction
Jakarta Commons Logging (JCL) provides a log (logging) interface (interface), taking into account both lightweight and not-dependent log implementation tools. It provides middleware/log tool developers with a simple log operation abstraction that allows program developers to implement tools with different specific log implementations. The user is assumed to be familiar with a higher level of detail for some kind of log implementation tool. JCL provides a simple wrapper for other log tools, including log4j, Avalon Logkit, and JDK 1.4, which is closer to log4j and Logkit implementations.
2. Quick Start
JCL has two basic abstract classes: log (base logger) and logfactory (responsible for creating the log instance). When Commons-logging.jar is added to the classpath, it may reasonably be able to guess the log tool you like, then set yourself up, and the user doesn't have to do anything. The default logfactory is to follow the steps below to discover and determine which log tool will be used (in order, the search process will be aborted when the first tool is found):
Find the value in the current factory named Org.apache.commons.logging.Log configuration property
Find the value in the system named Org.apache.commons.logging.Log in the attribute
If the application has log4j in its classpath, use the associated wrapper (wrapper) class (Log4jlogger)
If the application is running in a jdk1.4 system, use the associated wrapper class (Jdk14logger)
Use simple log wrapper class (Simplelog)
3, development and use of logging
Import related classes in program file header
Import Org.apache.commons.logging.Log;
Import Org.apache.commons.logging.LogFactory;
......
To get an instance of a class
public class MYCLASS
{
private static log log = Logfactory.getlog (Myclass.class);
...
}
Log information is sent to the logger, as in the previous example, log. This sending process is done by calling the method defined in the log interface, where different methods are associated with different levels, and the level of log information is indicated by which level of log information is sent. The methods defined in the Org.apache.commons.logging.Log interface are in the order of severity from highest to lowest:
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.isdebugenabled ();
Log.istraceenabled ();
Information level
It is important to ensure that the log information is appropriate to the content and to the severity of the response problem.
FatalA very serious error caused the system to abort. Expect this type of information to be immediately displayed on the status console.
ErrorOther run-time errors or conditions that are not expected. Expect this type of information to be immediately displayed on the status console.
warnUse APIs that are not in favor, very clumsy use of APIs, ' almost ' errors, other run-time undesirable and unexpected states but not necessarily called ' bugs '. Expect this type of information to be immediately displayed on the status console.
InfoA meaningful event that occurs at run time. Expect this type of information to be immediately displayed on the status console.
DebugDetail information in the system process. Expect this type of information to be written only in the log file.
TraceMore details of the information. Expect this type of information to be written only in the log file.
Typically, the logger's level should not be less than info. In other words, debug information should not normally be written to the log file.
Working mechanism
Life cycle
JCL Logfactory must implement a connection to the log tool, instantiate/Initialize/deconstruct a log tool. Exception handling
The JCL Log interface does not specify any exception handling, and the implementation of the interface must catch and handle exceptions. Multithreading DD
JCL log and Logfactory implementations must ensure that any log tool is required for parallelism.
Settings for loggers
The JCL of the logger used differs in its settings. LOG4J is the default preferred logger, which can be set by System properties or a property file, and the following is its set parameter.
Parameters |
Range |
Default value |
Description |
Log4j.configuration |
|
Log4j.properties |
Specify the name of the configuration file |
Log4j.rootcategory |
Priority [, appender]* |
|
Set the level of the root logger |
Log4j.logger<.logger.name> |
DEBUG, INFO, WARN, ERROR, or FATAL |
Set the level of logger.name this logger |
|
Log4j.appender<.appender>. Threshold |
Priority |
Specifies the lowest level of recording device Appender (console, files, sockets, and others). |
|