你的位置:首页 > 软件开发 > Java > INTRODUCING LOG4J 2 – ENTERPRISE CLASS LOGGING

INTRODUCING LOG4J 2 – ENTERPRISE CLASS LOGGING

发布时间:2016-03-07 18:00:11
If you are still using System.out to print debugging or diagnostic information in your application, it’s time to look for a mo ...

INTRODUCING LOG4J 2 – ENTERPRISE CLASS LOGGING

If you are still using System.out to print debugging or diagnostic information in your application, it’s time to look for a more elegant and efficient solution in the form of a logging framework. Although there are lots of logging frameworks around for Java applications, Log4J is one of the most widely adopted one because of the simplicity and flexibility it provides.

Note: The Log4J version 1 was first released on 1999 and quickly became the most used logging framework ever. But due to some inherent architectural flaws, Apache announced End of Life of Log4j version 1 on August 2015 and encouraged users to upgrade to Log4j 2 – A framework that is far more reliable, faster, and much easier to develop and maintain. Log4J 2 is almost a compete changed framework with a different API and support for different configuration files having different syntax. Therefore, from here onward, I will refer the framework as Log4J 2

Log4J 2 is an open source logging package distributed under the Apache Software License. The advantages it provides over System.out is monumental. Log4J 2 allows you to define different levels of importance, such asERROR, WARN, INFO, and DEBUG for log messages. Log4J 2 also allows you to define one or more destinations, such as console, file, database, and SMTP server to send log messages. And the great thing is that using Log4J 2, you can perform logging asynchronously.

Additionally, Log4J 2 allows you to control logging on a class-by-class basis. For example, one class of an application can redirect logs to the console while another to a file. By contrast, a programmer can only controlSystem.out at the granularity of the entire application. If a programmer redirects System.out, the redirect happens for the whole application.

Another important feature of Log4J 2 is that it’s easy to enable or disable only some type of log message. For example, you can configure Log4J 2 to disable every debug message in production.

So how Log4J 2 do all this? It’s through the loggers, appenders, and layouts  – the components of the Log4J 2 API. These components work together to provide developer full control on how messages are logged, formatted, and where they are reported.

  • loggers

Loggers are the key objects in Log4J 2 that are responsible for capturing logging information. Loggers are stored in a namespace hierarchy and a root logger, an implementation of the Logger interface, sits at the top of the hierarchy. Logger names are case-sensitive and they follow the hierarchical naming rule.

You can retrieve the root logger by calling the LoggerManager.getRootLogger() method. For all other loggers, you can instantiate and retrieve them by calling LoggerManager.getLogger(String loggerName) passing the name of the desired logger as a parameter. Although, you can specify any name for a logger, its recommend to name the logger with the fully qualified name of the class. In a large application, with thousands of log statements, it is easy to identify the origin of a log message as the log output bears the name of the generating logger. Since it is a common practice to name loggers after their owning class, Log4J 2 provides the overloaded convenience method LogManager.getLogger(). This method, by default, uses the fully qualified class name of the owning class.

Loggers can be assigned levels in the following order.

INTRODUCING LOG4J 2 – ENTERPRISE CLASS LOGGING

As you can see in the figure above, FATAL is the lowest level and the level moves up through ERROR, WARN,INFO, DEBUG till TRACE – the highest level. What this means is that if you set the logger level to ERROR then only the ERROR and FATAL level log messages will be displayed and the rest will be ignored.

In addition to the levels I mentioned, there are two special levels:

  • ALL: Turns on all levels.
  • OFF: Turns off all levels.

While developing in your local machine, it is common to set the log level to DEBUG. This will give you detailed log messages for your development use. While on production, its typical set the log level to ERROR or higher. This is to avoid filling your logs with excessive debug information. And while logging is very efficient, there is still a cost.

In your application, once you have retrieved a logger, you call one of the printing methods debug(), info(),warn(), error(), fatal(), and log() on the logger to log messages. These messages are contained in the Loggerinterface and part of the root logger that all Log4J 2 loggers inherit.

  • Appenders

Once you capture logging information through a logger, you need to send it to an output destination. The output destination is called an appender, and it is attached to the logger. Log4J 2 provides appenders for console, files, GUI components, remote socket servers, JMS, NT Event Loggers, and remote UNIX Syslog daemons.

Appenders are inherited additively from the logger hierarchy. This means, if the console appender is attached to the root logger, all child loggers will inherently use the console appender. If you have a child logger named Foo attached with a file appender, then Foo will use both the console and file appenders, unless you explicitly ask it not to do so by setting the additivity attribute to false.

  • Layouts

In addition to specifying your preferred output destination, you can also specify the format of log messages. You can do so by associating a layout with the appender. Some key layouts that Log4J 2 provides arePatternLayout, Htmlayout, JsonLayout, and 

  • Using Log4j 2

Let’s jumpstart to create a trivial application to use Log4J 2 and start logging. For the application, I have used Spring Boot and started out with a Spring Boot starter POM. If you are new to Spring Boot, you can start with my introductory post on Spring Boot here.

As the Spring Boot starter POM uses Logback for logging, you need to exclude it and add the Log4J 2 dependencies.

Here is the code of the POM file to use Log4J 2 in a Spring Boot application.

 1 . . . 2 <dependency> 3   <groupId>org.springframework.boot</groupId> 4   <artifactId>spring-boot-starter</artifactId> 5   <exclusions> 6    <exclusion> 7      <groupId>org.springframework.boot</groupId> 8      <artifactId>spring-boot-starter-logging</artifactId> 9   </exclusion>10  </exclusions>11 </dependency>12 <dependency>13   <groupId>org.apache.logging.log4j</groupId>14   <artifactId>log4j-api</artifactId>15   <version>2.5</version>16 </dependency>17 <dependency>18   <groupId>org.apache.logging.log4j</groupId>19   <artifactId>log4j-core</artifactId>20   <version>2.5</version>21 </dependency>22 . . .

原标题:INTRODUCING LOG4J 2 – ENTERPRISE CLASS LOGGING

关键词:

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。

可能感兴趣文章

我的浏览记录