1 Brief Introduction
1.1 log4net The advantages:
Almost all large applications will have their own APIs for tracking debugging. Because once a program is deployed, it is less likely to use specialized debugging tools. However, an administrator may need a strong logging system to diagnose and fix configuration problems.
Experience shows that logging is often an important part of the software development cycle. It has the following advantages: it provides an accurate environment for the runtime of the application, allows developers to quickly find bugs in the application, and once the log output code is added to the program, the program can generate and output log information without human intervention. In addition, log information can be exported to different places (consoles, files, etc.) for future research purposes.
Log4net is designed for such a purpose. NET development environment's log pack.
1.2 log4net the installation:
Users can download the log4net source code from http://logging.apache.org/log4net/. After you unpack the package, load the Log4net.sln into visual Studio. NET in the unzipped src directory, and you can get log4net.dll after compiling. The user wants to add the log function in own program, only then can the Log4net.dll introduce the project.
2 log4net The Structure
Log4net has four main components, namely Logger (recorder), Repository (library), Appender (attachment) and Layout (layout).
2.1 Logger
2.1.1 Logger Interface
Logger is the main component of an application that needs to interact, and it is used to generate log messages. The resulting log messages are not displayed directly, but are not output until the layout format is processed beforehand.
Logger provides a variety of ways to record a log message, you can create multiple logger in your application, and each instantiated logger object is maintained by the Log4net framework as a named entity (named entity). This means that in order to reuse a logger object, you do not have to pass it among different classes or objects, just call it by its name as a parameter. The Log4net framework uses the inheritance system, which is similar to the inheritance system. The name space in net. In other words, if there are two logger, respectively defined as A.B.C and a.b, then we say that A.B is the ancestor of A.B.C. Each logger inherits the attributes of the ancestors.
The log4net framework defines a ilog interface, and all logger classes must implement this interface. If you want to implement a custom logger, you must first implement this interface. You can refer to a few examples in the/extension directory.
The Ilog interface is defined as follows:
public interface ILog
{
void Debug (object message);
void Info (object message);
void Warn (object message);
void Error (object message);
void Fatal (object message);
Each of these methods has an overloaded method to support exception handling.
Each overloaded method is shown as follows, with an additional parameter for an exception type.
void Debug (Object message, Exception ex);
// ...
The Boolean property is used to check the log level of the logger
(We'll see the log level immediately later)
BOOL isdebugenabled;
BOOL isinfoenabled;
... Boolean Properties for other methods
}
The Log4net framework defines a class called Logmanager, which is used to manage all logger objects. It has a getlogger () static method that retrieves an existing logger object using the name parameter we provide. If the Logger object does not exist in the frame, it will also create a logger object for us. The code looks like this:
Log4net. ILog log = log4net. Logmanager.getlogger ("Logger-name");
In general, we call GetLogger () with the class (type) as the parameter to track the class that we are logging on. The type of class that is passed can be obtained using the typeof (Classname) method, or it can be obtained by using the following reflection method:
System.Reflection.MethodBase.GetCurrentMethod (). DeclaringType
Although the symbols are longer, the latter can be used in some situations, such as getting the type of Class (type) that invokes the method.
2.1.2 level of the log
As you can see in the Ilog interface, there are five different ways to track an application. In fact, these five methods operate on different log priority levels set by the Logger object. These different levels are defined as constants in the Log4net.spi.Level class. You can use any of the methods in your program. But in the final release you may not want all the code to waste your CPU cycles, so the framework provides 7 levels and corresponding Boolean attributes to control the type of logging.
Level has the following values
level |
Allowed Methods |
Boolean Property |
Priority Level |
off |
|
|
Highest |
FATAL |
void Fatal (...); |
bool isfatalenabled; |
|
rror |
void Error (...); |
bool iserrorenabled; |
|
WARN |
void Warn (...); |
bool iswarnenabled; |
|
INFO |
void Info (...); |
bool isinfoenabled; |
|
DEBUG |
void Debug (...); |
bool isdebugenabled; |
|
All |
|
|
Lowest |
Table 1 Logger log levels
In the Log4net framework, each log object is assigned a log priority by setting the configuration file. If you do not explicitly assign a level to a log object, the object attempts to inherit a level value from his ancestors.
Each method of the Ilog interface has a predefined level value. As you can see in table 1, the Ilog inof () method has the info level. Similarly, and so on, the error () method has an error level. When we use either of these methods, the Log4net framework examines the level of the Log object logger and the level of the method. Log requests are accepted and executed only if the method has a higher level than the log level.
For example, when you create a log object and set his level to info. The framework then sets each Boolean property of the log. When you call the corresponding log method, the framework checks the corresponding Boolean property to determine whether the method can be executed. Like the following code:
Logger.info ("message");
Logger.debug ("message");
Logger.warn ("message");
For the first method, the level of info () and the level of the log (info), so the log request is passed and we can get the output "message".
For the second method, the level of Debug () is lower than the log level (INFO) of the log object logger, so the log request is rejected and we do not get any output. Similarly, for the third line of statements, we can easily draw a conclusion.
There are two special levels in table 1: All and off. All indicates that all log requests are allowed. Off is to reject all requests.
You can also explicitly check the Boolean properties of the Logger object, as follows:
if (logger. isdebugenabled)
{
Logger.debug ("message");
}
2.2 Repository
Repository is mainly used to maintain the organization structure of log objects. In previous versions of Log4net, the framework supported only hierarchical organizational structures (hierarchical organization). This hierarchical structure is essentially an implementation of the library and is defined in log4net. Repository.hierarchy the name space. To implement a repository, you need to implement log4net. Repository.iloggerrepository interface. However, this interface is not usually implemented directly, but rather with log4net. Repository.loggerrepositoryskeleton is inherited by the base class. The System library (hierarchical repository) is composed of log4net. Repository.Hierarchy.Hierarchy class implementation.
If you are a user of a log4net framework, not an extender, you will rarely use repository classes in your code. Instead, you need to use the Logmanager class to automate the management of libraries and log objects.
2.3 Appender
A good log framework should be able to produce multiple destinations of output. For example, output to the console or saved to a log file. Log4net can meet these requirements very well. It uses a component called Appender to define the output media. As the name shows, these components attach them to the Logger log component and pass the output to the output stream. You can attach multiple Appender components to a log object. The Log4net framework provides several appender components. A complete list of the Appender components provided by Log4net can be found in the Log4net Framework's help manual. With these out-of-the-box appender components, you generally don't have to write them yourself. But if you want, you can get from log4net. Appender.appenderskeleton class inheritance.
2.4 Appender Filters
A Appender object passes all log events to the output stream by default. Appender Filters (Appender Filters) can filter log events according to different criteria. In Log4net. There are already several predefined filters under the name space of the filter. With these filters, you can filter log events according to the log level range, or filter by a particular string. You can find more information about the filter in the Help file of the API.
2.5 Layout
The Layout component is used to display the last formatted output information to the user. The output information can be displayed in a variety of formats, depending primarily on the type of layout component we use. can be linear or an XML file. The layout component works with a Appender component. List of different layout components in the API help book. A Appender object that can only correspond to one layout object. To achieve your own layout class, you need to get from log4net. Layout.layoutskeleton class inheritance, which implements the Ilayout interface.
3 using log4net in your program
Before you start logging your program, you need to start the Log4net engine first. This means that you need to first configure the three components mentioned earlier. You can set the configuration in two ways: Configure the configuration in a separate file or define the configuration in code.
For the following reasons, it is recommended that you define the configuration in a separate file:
L You do not need to recompile the source code to change the configuration;