As a Java programmer, I think many of you know the importance of logging to a program, especially a Web application. Many times, logging may be the only way we know how an application is performing.
So, logging is very important in Java Web applications, but many people tend to think that logging is a simple task, so they often ignore the problems associated with logging.
In this article, I’m going to introduce you to one of the most overlooked things that can also lead to failures.
The Java language is powerful because of its mature ecosystem. Including logging, there are many mature open source frameworks that can be used directly.
First, let’s take a look at what frameworks are widely used today.
Common Logging frameworks
j.u.l
The Java logging framework introduced in JDK 1.4 is known as the Receip.u.L, which stands for the Java.util. logging package. The Java Logging API provides seven Logging levels to control the output. The seven levels are SEVERE, WARNING, INFO, CONFIG, FINE, FINER, and FINEST.
Log4j
Log4j is an open source project of Apache. By using Log4j, you can control the destination of log messages to the console, files, GUI components, even the socket server, NT event logger, UNIX Syslog daemon, etc. We can also control the output format of each log;
By defining the level of each log message, we can more carefully control the log generation process. Log4 also has seven log levels: OFF, FATAL, ERROR, WARN, INFO, DEBUG, and TRACE.
The most interesting thing is that these can be configured flexibly through a configuration file without the need to modify the application code.
LogBack 
LogBack is also a mature logging framework. In fact, LogBack and Log4j came from the same person, Ceki Gulcu.
Logback is currently divided into three modules: logback-core, logback-classic, and logback-access.
Logback-core is the base module for the other two modules.
Logback-classic is an improved version of Log4j. In addition, logback-Classic fully implements the SLF4J API so that you can easily switch to other journaling systems such as Log4j or J.U.L.
The Logback-Access access module integrates with the Servlet container to provide access to diaries over Http.
Log4j2
Log4j2 has been introduced separately from log44J because Log4j2 is not just an updated version of Log4j, but has been rewritten from the ground up, which can be interpreted as two completely different frameworks.
We’ll cover what problems Log4j2 solves with Log4j and what advantages Log4j2 has over Log4j, J.U.L, and LogBack in future articles.
Disallow direct use of the Log framework API?
Four logging frameworks were introduced, which means that we can use any of the four libraries when we want to print logs in our applications. For example, if you want to use Log4j, you simply rely on the Log4j JAR package, configure the configuration file, and print logs using its API in your code.
I do not know how many people have read the “Alibaba Java development Manual”, which has a specification to do “mandatory” requirements:
The four commonly used logging frameworks are designed to make logging easy for Java applications, so why not use their apis directly in your applications? What SLF4J is recommended for use here? What about the facade model?
What is a journal facade
Log facade is a typical application of facade mode.
Facade Pattern, also known as Facade Pattern, its core is: external communication with a subsystem must be carried out through a unified Facade object, making the subsystem easier to use.
As with the previous logging frameworks, each logging framework has its own API, and using the corresponding framework requires using the corresponding API, which greatly increases the coupling of application code to the logging framework.
The solution to this problem is to create a bridge between the logging framework and the application, so that the application does not need to be aware of any changes in the underlying logging framework. As long as the facade service is good enough, feel free to switch to another logging framework, and the application can go live without changing a single line of code.
There is a saying in software development that any problem in computer science can be solved by adding an indirect middle layer. The facade model is a typical practice of this sentence.
Why do I need a log facade
One important reason mentioned earlier is to shield the implementation of the underlying logging framework from the application. That way, even if one day you need to change your code’s logging framework, you only need to change the JAR package, and at most the configuration file related to logging output. This decoupled the application from the logging framework.
Some people may ask, if I change the logging framework, the application does not need to change, that log facade does not need to change?
To answer this question, let’s take an example, and then crumple up the facade and explain it all over again.
The journal facade is like a waiter in a restaurant, while the journal framework is like a cook in the back kitchen. For the customer application, when I go to a restaurant and order, ALL I have to do is tell the waiter I want a plate of scrambled eggs and tomatoes, I don’t care about everything in the kitchen. Because although the chef changed from chef A who called it “tomato scrambled eggs” to Chef B who called it “tomato scrambled eggs”. However, the customer does not need to care, he just issued the “tomato scrambled eggs” command to the waiter, the waiter to translate it to the chef.
So, for a waiter who knows the various names of “tomato and egg”, no matter how the chef changes, he can accurately help users order.
Similarly, a well-designed, well-rounded logging facade should be naturally compatible with multiple logging frameworks. Therefore, the replacement of the underlying framework, almost no change in the log facade.
This is one of the more important benefits of logging facades – decoupling.
Common log facade
With the concept and benefits of logging fronts covered, let’s take a look at what good logging facade implementations are available in the Java ecosystem.
SLF4J 
Java Simple Logging Facade for Java (ABBREVIATED SLF4J) is an interface program that wraps the Logging framework and is implemented in Facade mode. You can decide which Logging framework to use during software deployment. Currently, Java Logging API, Log4j, logBack and other frameworks are supported. Distributed under an MIT license.
SLF4J is written by Ceki Gulcu, author of Log4j and Logback, who claims that SLF4J is more efficient than Log4j and simpler and more stable than Apache Commons Logging (JCL).
In fact, SLF4J is just a facade service, it is not a real logging framework, the real log output related implementation or rely on Log4j, Logback and other logging framework.
Since SLF4J is more commonly used, here is a brief analysis of SLF4J, mainly compared to Log4J. SLF4J has the following advantages over Log4J’s API:
Copy the code // The traditional string generation method wastes time generating unnecessary messages without logging Debug level messages
logger.debug("There are now " + count + " user accounts: " + userAccountList);
// To avoid the above problems, you can check whether the Debug message recording function is enabled first, but the coding of the program is complicated
if (logger.isDebugEnabled()) {
logger.debug("There are now " + count + " user accounts: " + userAccountList);
}
// If the Debug level is not enabled, unnecessary strings will not be generated, while keeping the program code concise
logger.debug("There are now {} user accounts: {}", count, userAccountList);
Commons – logging 
Apache Commons Logging is a Java-based Logging utility that is a programming model for Logging and other toolkits. It provides APIS, logging implementations, and wrapper implementations through several other tools.
Commons-logging is similar to SLF4J in that it is primarily used as a logging facade. Provide more friendly API tools.
conclusion
There are many mature solutions around logging in the Java ecosystem. There are two main types of tools for logging output.
One is the log framework, mainly used for the output of the log, such as output to which file, log format and so on. The other is the logging facade, a set of generic apis designed to mask the differences between logging frameworks.
Therefore, the best practice for Java engineers with regard to the use of logging tools is to use a combination such as Log4j + SLF4J for logging in their applications.
The biggest benefit of this approach is that business layer development does not need to care about the implementation and details of the underlying logging framework, and coding does not need to consider the cost of replacing the framework later. This is also the benefit of the facade model.
In summary, do not use any logging framework apis such as Log4j in your Java code, and instead use SLF4J as a logging facade.
The original article was published on November 29, 2018
Author: Hollis
This article is from the cloud community partner “Programmer Grey”. For more information, please pay attention to “Programmer Grey”.