Jakarta commons logging Study Notes-sauteed meat with bamboo shoots

Jakarta commons logging Study Notes

To be honest, jcl (Jakarta commons logging) and log4j have really blinded me. Isn't it all about log? Why is there a log4j package in the jcl source code package? Who and who? You can only understand the jcl user guide. Hehe.

1. Introduction to commons-Loggin

Jakarta commons logging (jcl) provides a log interface that is lightweight and independent from specific log implementation tools. It provides a simple log operation abstraction for middleware/log Tool developers, allowingProgramDevelopers use different log implementation tools. The user is assumed to be familiar with more advanced details of a log implementation tool. Interfaces provided by jcl are simply packaged for other log tools, including log4j, aveon logkit, and JDK 1.4. This interface is closer to the implementation of log4j and logkit.
2. Quick Start

Jcl has two basic abstract classes: log (Basic recorder) and logfactory (responsible for creating log instances ). When the commons-logging.jar is added to the classpath, it may reasonably guess your favorite logging tool and then perform self-setting, and the user does not need to do anything at all. The default logfactory discovers and determines which log tool will be used (in order, the search process will stop when the first tool is found) according to the following steps ):

1. Search for the value of the Configuration Attribute org. Apache. commons. Logging. log in the current factory.
2. Search for the value of org. Apache. commons. Logging. log in the system attribute.
3. If the application classpath contains log4j, use the related Wrapper class (log4jlogger)
4. If the application runs in the jdk1.4 system, use the related packaging class (jdk14logger)
5. Use simple log packaging class (simplelog)

3. Develop and use logging

// Import related classes in the program file header
Import org. Apache. commons. Logging. log;
Import org. Apache. commons. Logging. logfactory;
......
// Obtain an instance in the class
Public class myclass
{
Private Static log = logfactory. getlog (myclass. Class );
...
}

The log information is sent to the recorder, as shown in the preceding example. This sending process is completed by calling the methods defined in the log interface. Different methods are associated with different levels. At which level the log information is sent, indicates the log information level. Methods defined in the org. Apache. commons. Logging. Log interface are sorted in the order of severity from high to low:

1. Log. Fatal (Object message );
2. Log. Fatal (Object message, throwable t );
3. Log. Error (Object message );
4. Log. Error (Object message, throwable t );
5. Log. Warn (Object message );
6. Log. Warn (Object message, throwable t );
7. Log.info (Object message );
8. Log.info (Object message, throwable t );
9. Log. debug (Object message );
10. Log. debug (Object message, throwable t );
11. Log. Trace (Object message );
12. Log. Trace (Object message, throwable t );

In addition, the following methods are providedCodeProtection.

1. Log. isfatalenabled ();
2. Log. iserrorenabled ();
3. Log. iswarnenabled ();
4. Log. isinfoenabled ();
5. Log. isdebugenabled ();
6. Log. istraceenabled ();

Information level
It is important to ensure that the log information is appropriate in terms of content and severity of the problem.

1. FatalA very serious error causes the system to stop. This type of information is expected to be immediately displayed on the Status console.
2. ErrorOther runtime errors or unexpected conditions. This type of information is expected to be immediately displayed on the Status console.
3. WarnWhen you use an API that is not in favor of the use, it is very poor to use the API. 'It is almost a' error. Other running statuses are not required or unexpected, but it is not necessary to call them "errors ". This type of information is expected to be immediately displayed on the Status console.
4. InfoMeaningful events generated during running. This type of information is expected to be immediately displayed on the Status console.
5. DebugDetailed information in the system flow. It is expected that such information will only be written into the log file.
6. TraceMore detailed information. It is expected that such information will only be written into the log file.

Generally, the recorder level should not be lower than info. That is to say, the debug information should not be written into the log file.
Working mechanism

1. Lifecycle
   Jcl logfactory must establish/disconnect the connection to the log tool and instantiate/initialize/deconstruct a log tool.
2. Exception Handling
   The jcl log interface does not specify any exception handling. The implementation of the interface must capture and handle exceptions.
4. Multithreading
   The implementation of jcl log and logfactory must ensure the parallel requirements of any log tool.

Recorder settings
Jcl uses different recorder settings. Log4j is the default preferred recorder. You can set log4j through system properties or an attribute file. The following are the setting parameters.

Parameters	Value Range	Default Value	Description
Log4j. Configuration		Log4j. Properties	Name of the configuration file
Log4j. rootcategory	Priority [, appender] *		Set the root recorder level
Log4j. Logger <. Logger. Name>	Debug, info, warn, error, or fatal	Set the logger. Name level.
Log4j. appender <. appender>. Threshold	Priority	Specifies the minimum appender (console, files, sockets, and others) of the recording device.

Posted by Hilton at October 20,200 3 pm | trackback