Java Log API
Functionally, the functionality required by the log API itself is simple enough to be able to record a piece of text. The user of the API constructs the corresponding text information according to the current context information when it needs to record, and invokes the API to complete the record. In general, the log API consists of the following sections:
- Recorder (Logger): The user of the log API makes logging requests through the logger and provides the contents of the log. When logging, you need to specify the severity level of the log. When logging is required in a program, you first need to get a logger object. The general logging API provides the appropriate factory method to create a logger object. Each Logger object is a name. The general practice is to use the name of the current Java class or the name of the package as the name of the Logger object.
- Formatter (Formatter): Formats the text recorded by the logger and adds additional metadata. Some metadata is included in the log that is actually logged in addition to the message that is provided when the Logger object is used. These metadata are provided by the logging framework. Common information includes the name of the logger, time stamp, thread name, and so on. The formatter is used to determine how all this information is displayed in the log record. Different logging implementations provide their own default formatting and custom support.
- Processor (Handler): Outputs the formatted log records to a different location. Common log output targets include consoles, files, databases, and so on.
Java Log Encapsulation API
Encapsulation Library in the beginning of the Apache Commons Logging Framework is the most popular, now more popular is slf4j. This encapsulates the library's API is relatively simple, only in the logging library API based on a simple package, masking the differences between the different implementations. Because the logging implementation provides an API that is broadly similar, the role of the wrapper library is to achieve syntactic consistency.
In the Apache Commons Logging Library, the core API is the Org.apache.commons.logging.LogFactory class and the Org.apache.commons.logging.Log interface. The Logfactory class provides the implementation object that the factory method uses to create the Log interface. For example, Logfactory.getlog can create a LOG interface implementation object based on the Java class or name. The Log interface defines a set of methods for each of the 6 different severity levels. For example, for the debug level, isdebugenabled (), Debug (Object message), and debug (object message, Throwable T) three methods are defined. From this level, the log interface simplifies the use of the logger.
The SLF4J library is used in a similar way to the Apache Commons Logging Library. The core API in the SLF4J library is the Org.slf4j.Logger interface that provides the Org.slf4j.LoggerFactory class and logging of the factory method. Gets the logger object through the GetLogger method of the Loggerfactory class. Similar to the Log interface in the Apache Commons Logging Library, the methods in the Logger interface are grouped by different severity levels. The same isdebugenabled method is found in the Logger interface. However, methods such as debug that issue logging requests in the Logger interface use String types to represent messages, and messages that contain parameters can be used.
Comparison between SLF4J and common-logging
common-loggingThe dynamic lookup mechanism automatically finds the log library that is actually used when the program runs. Because it uses ClassLoader to find and load the underlying log library, a framework like OSGi does not work properly because OSGi's different plugins use their own classloader. This mechanism of OSGI ensures that plug-ins are independent of each other, but it makes Apache common-logging unable to work.
slf4jThe real log library is statically bound at compile time, so it can be used in OSGi. In addition, SLF4J supports parameterized log strings, avoiding the need to write the IF (logger.isdebugenable ()) that was previously written to reduce the performance loss of string concatenation, and now you can write directly: Logger.debug ("Current user is: {} ", user). The assembly message was postponed until it was able to determine whether to display the message, but the cost of acquiring the parameter was not spared.
Log Framework ImplementationLog4japache an open source project, through the use of log4j, we can control the destination of log information delivery is the console, files, GUI components, even the socket server, NT Event recorder, UNIX syslog daemon, etc. The user can also control the output format of each log, and by defining the level of each log information, the user can control the log generation process more carefully. These can be configured flexibly with a single configuration file without the need to modify the program code.
Logbacklogback is another open source journaling component designed by the founder of Log4j. The Logback is currently divided into three modules: Logback-core,logback-classic and logback-access. The Logback-core is the base module for the other two modules. Logback-classic is an improved version of log4j. In addition logback-classic full implementation of the SLF4J API allows you to easily change to other journaling systems such as log4j or JDK14 Logging. The Logback-access Access module integrates with the servlet container to provide the ability to access journaling over HTTP.
Log4j and Logback compare Logback as a general reliable, fast and flexible log framework that will act as an alternative to log4j and slf4j a complete implementation of the new log system. Logback claims to have excellent performance, "some key operations, such as determining whether to record a log statement operation, its performance has been significantly improved." This operation requires 3 nanoseconds in Logback and 30 nanoseconds in log4j. The logback creates a logger (logger) faster: 13 microseconds, while in log4j it takes 23 microseconds. What's more, it takes only 94 nanoseconds to get the existing logger, and the log4j takes 2234 nanoseconds and the time is reduced to 1/23. Performance improvements compared to Jul are also significant. " In addition, all logback documents are provided free of charge, unlike log4j, which only provides some free documentation and requires users to purchase paid documents.
SummaryInterface: All log implementations are fitted together and invoked with a unified interface.
Implementation: The current mainstream log implementation
Old log to SLF4J adapter: If the use of slf4j, but only want to use an implementation, want to log4j log system from Logback output, this is very useful.
SLF4J to implemented adapters: These packages are required if you want to develop a specific implementation of SLF4J.
SLF4J relationship to the old log frame
slf4j equals commons-logging, is a common entry for various log implementations, depending on which jar exists in the classpath to determine the specific log implementation library.
Logback-classic (default Logback implementation)
Slf4j-jcl.jar (Apache Commons logging)
Slf4j-logj12.jar (log4j 1.2.4)
Slf4j-jdk14 (java.util.logging)
go to SLFJ for all log calls to a third-party class library or old code that uses the legacy log API
Jcl-over-slf4j.jar/jcl104-over-slf4j:apache Commons Logging 1.1.1/1.0.4, can be replaced directly.
LOG4J-OVER-SLF4J.JAR:LOG4J, the direct replacement can be.
JUL-TO-SLF4J:JDK logging, you need to call Slf4jbridgehandler.install () at the beginning of the program to register the Listener reference Juloverslf4jprocessor, The bean can be defined in Applicationcontext.xml for initialization. Note that the original log4j.properites will expire, and the Logback website provides converters that support conversion from log4j.properties to Logback.xml. Log component related history there are many tools to implement logging in the Java World, the first widely used is log4j, and the log parts of many applications are given to log4j, but as component developers, they want their components to not rely on a single tool, After all, there are a lot of other log tools at the same time, and if an application uses two components and exactly two components use different logging tools, then the application will have two log output.
In order to solve this problem, Apache Commons Logging (previously called Jakarta Commons LOGGING,JCL), the JCL only provides log interface, the implementation is dynamically looking at runtime. As a result, the component developer only needs to develop for the JCL interface, while the calling component's application can be run with its own favorite log practice tool.
So even now you will still see a lot of program application JCL + log4j this collocation, but when the size of the program is becoming larger and bigger, the JCL dynamic binding is not always successful, specific reasons we can Google a bit, here will not repeat. One of the workarounds is to statically bind the specified log tool when the program is deployed, which is why slf4j occurs.
Like JCL, SLF4J is only provided with the log interface, the implementation of the application is packaged in the binder (named Slf4j-xxx-version.jar) to decide, XXX can be log4j12, jdk14, JCL, NOP, etc., they realized the The binding and proxy work of the Body log tool (such as log4j). For example: If a program wants to use the LOG4J log tool, then the program only needs to be programmed for the Slf4j-api interface and then put in Slf4j-log4j12-version.jar and Log4j.jar when it is packaged.
Now there is a problem, if you are using the JCL in the component that you are developing the application, and some of the builds may call java.util.logging directly, then you need a bridge (named Xxx-over-slf4j.jar) redirect their log output to slf4j, the so-called bridge is a fake log implementation tool, such as when you put Jcl-over-slf4j.jar to Class_path, even if a component was originally through the JCL Output log, but now will be jcl-over-slf4j "cheat" slf4j, and then SLF4J will be based on the binding to the log to the specific log implementation tool. The process is as follows
Component
|
| Log to Apache Commons Logging
V
Jcl-over-slf4j.jar---(redirect)---> slf4j---> Slf4j-log4j12-version.jar---> Log4j.jar---> Output log
Seeing the flowchart above may find an interesting question, what happens if you place Log4j-over-slf4j.jar and Slf4j-log4j12-version.jar in Class_path? Yes, the logs will be kicked and kicked, eventually going into the dead loop.
So the typical collocation of using slf4j is to place the 5 jars of the Slf4j-api, JCL Bridge, Java.util.logging (JUL) bridge, log4j Binder, and log4j in Class_path.
However, not all app containers are used log4j, such as Google AppEngine it uses java.util.logging (JUL), then the application slf4j with the Slf4j-api, JCL Bridge, Logj4 Bridge Connector, The 4 jars of the Jul binder are placed in the web-inf/lib. http://blog.jobbole.com/51155/http://phl.iteye.com/blog/2021461http://blog.csdn.net/yycdaizi/article/details/8276265
2015 30th Thursday Java Log Component
