SLF4J user manual 专题

System Out and Err Redirected to SLF4J

The sysout-over-slf4j module allows a user to redirect all calls to System.out and System.err to an SLF4J defined logger with the name of the fully qualified class in which the System.out.println (or similar) call was made, at configurable levels.

What are the intended use cases?

The sysout-over-slf4j module is for cases where your legacy codebase, or a third party module you use, prints directly to the console and you would like to get the benefits of a proper logging framework, with automatic capture of information like timestamp and the ability to filter which messages you are interested in seeing and control where they are sent.

The sysout-over-slf4j module is explicitly not intended to encourage the use of System.out or System.err for logging purposes. There is a significant performance overhead attached to its use, and as such it should be considered a stop-gap for your own code until you can alter it to use SLF4J directly, or a work-around for poorly behaving third party modules.
​​​http://projects.lidalia.org.uk/sysout-over-slf4j/index.html​​

Quick Start
Add sysout-over-slf4j to the classpath
Download the sysout-over-slf4j-1.0.2.jar on the Downloads page.http://github.com/Mahoney/sysout-over-slf4j/downloads
Alternatively, add the following to your maven pom dependencies:

<dependency>
        <groupId>uk.org.lidalia</groupId>
        <artifactId>sysout-over-slf4j</artifactId>
        <version>1.0.2</version>
</dependency>

桌面应用：

In a Standalone Application

Make the following call as early as possible in the startup of your application:

import uk.org.lidalia.sysoutslf4j.context.SysOutOverSLF4J;

public class App {
    public static void main(String[] args) {
        SysOutOverSLF4J.sendSystemOutAndErrToSLF4J();
        //start app
    }
}

Web应用：

In a Servlet Container

Add the following to your web.xml:

<listener>
  <listener-class>uk.org.lidalia.sysoutslf4j.context.SysOutOverSLF4JServletContextListener</listener-class>
</listener>

or

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import uk.org.lidalia.sysoutslf4j.context.SysOutOverSLF4JServletContextListener;


@Configuration
public class SysOutOverSLF4JConfig {

    @Bean
    public SysOutOverSLF4JServletContextListener sysOutOverSLF4JServletContextListener() {
        return new SysOutOverSLF4JServletContextListener();
    }

}

​​http://projects.lidalia.org.uk/sysout-over-slf4j/quickstart.html​​http://projects.lidalia.org.uk/sysout-over-slf4j/faq.html

slf4j中MDC是什么鬼
slf4j除了trace、debug、info、warn、error这几个日志接口外，还可以配合MDC将数据写入日志。换句话说MDC也是用来记录日志的，但它的使用方式与使用日志接口不同。
在使用日志接口时我们一般这么做

Logger LOG = LoggerFactory.getLogger("LOGNAME_OR_CLASS");
if(LOG.isDebugEnabled()) {
　　LOG.debug("log debug");
}

MDC从使用方式上有些不同,我对它的理解是MDC可以将一个处理线程中你想体现在日志文件中的数据统一管理起来，根据你的日志文件配置决定是否输出。

比如以下但不限于以下场景可以考虑使用MDC来达到目的

我们想在日志中体现请求用户IP地址
用户使用http客户端的user-agent
记录一次处理线程的日志跟踪编号(这个编号目的是为了查询日志方便，结合grep命令能根据跟踪编号将本次的处理日志全部输出)

MDC的使用
　　org.slf4j.MDC我个人会用AOP或Filter或Interceptor这类工具配合使用，获得你希望输出到日志的变量并调用MDC.put(String key, String val)，比如下面代码片段第5行：

@Around(value = "execution(* com.xx.xx.facade.impl.*.*(..))", argNames="pjp")
  public Object validator(ProceedingJoinPoint pjp) throws Throwable {
      try {
          String traceId = TraceUtils.begin();
          MDC.put("mdc_trace_id", traceId);
          Object obj = pjp.proceed(args);
          return obj;
      } catch(Throwable e) {
          //TODO 处理错误
      } finally {
          TraceUtils.endTrace();
      }
  }

代码通过AOP记录了每次请求的traceId并使用变量"mdc_trace_id"记录，在日志配置文件里需要设置变量才能将"mdc_trace_id"输出到日志文件中。我以logback配置文件为例,看日志第10行%X{mdc_trace_id}：

<appender name="ALL" class="ch.qos.logback.core.rolling.RollingFileAppender">
      <file>${CATALINA_BASE}/logs/all.log</file>
      <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
          <!-- daily rollover -->
          <fileNamePattern>${CATALINA_BASE}/logs/all.%d{yyyy-MM-dd}.log</fileNamePattern>
          <!-- keep 30 days' worth of history -->
          <maxHistory>30</maxHistory>
      </rollingPolicy>
      <encoder charset="UTF-8">
          <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - traceId:[%X{mdc_trace_id}] - %msg%n</pattern>
      </encoder>
  </appender>

MDC带来的好处
如果你的系统已经上线，突然有一天老板说我们增加一些用户数据到日志里分析一下。如果没有MDC我猜此时此刻你应该处于雪崩状态。MDC恰到好处的让你能够实现在日志上突如其来的一些需求
如果你是个代码洁癖，封装了公司LOG的操作，并且将处理线程跟踪日志号也封装了进去，但只有使用了你封装日志工具的部分才能打印跟踪日志号，其他部分(比如hibernate、mybatis、httpclient等等)日志都不会体现跟踪号。当然我们可以通过linux命令来绕过这些困扰。
使代码简洁、日志风格统一

Chapter 8: Mapped Diagnostic Context
​​​https://logback.qos.ch/manual/mdc.html​​​
通过slf4j/log4j的MDC/NDC 实现日志追踪

在分布式系统或者较为复杂的系统中，我们希望可以看到一个客户请求的处理过程所涉及到的所有子系统\模块的处理日志。
由于slf4j/log4j基本是日志记录的标准组件，所以slf4j/log4j成为了我的重点研究对象。
slf4j/log4j支持MDC，可以实现同一请求的日志追踪功能。
基本思路是：
实现自定义Filter，在接受到http请求时，计算eventID并存储在MDC中。如果涉及分布式多系统，那么向其他子系统发送请求时，需要携带此eventID。

其中：

response.setHeader("eventsign", eventsign);
很有用，返回的response中，将有httpheader：eventsign:000010x1489108079237

log4j日志格式配置为：
log4j.appender.stdout.layout.ConversionPattern=%d %logger-%5p - %X{eventid} - %m%n

在web.xml中配置自定义filter:

<!--start  log4jfilter-->
    <filter>
        <filter-name>log4jfilter</filter-name>
        <filter-class>org.fgq.study.log4j.Log4jFilter</filter-class>
        <init-param>
            <param-name>sign</param-name>
            <param-value>000010x</param-value>
        </init-param>
     </filter>
    <filter-mapping>
        <filter-name>log4jfilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>  
    <!--end  log4jfilter-->

doFilterInternal方法：

protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {

        String eventsign;

        if (request.getHeader("eventsign") == null || request.getHeader("eventsign").length() == 0) {
            eventsign = this.sign + String.valueOf(new Date().getTime()); //计算eventID

            logger.error("set eventid:" + eventsign);
        } else {
            eventsign = request.getHeader("eventsign");//从请求端获取eventsign
            logger.error("get eventid from request:" + eventsign);

        }

        MDC.put("eventid",  eventsign);
        response.setHeader("eventsign", eventsign);
        filterChain.doFilter(request, response);


    }

Log4jFilter-doFilterInternal

测试结果：

1、

Request URL:http://localhost:8084/spmvc/index.html
Request Method:GET
Status Code:304 Not Modified
Remote Address:[::1]:8084

Response Headers
Date:Fri, 10 Mar 2017 03:20:01 GMT
ETag:W/"660-1489115626000"
eventsign:000010x1489116001756

服务器端日志：
2017-03-10 11:20:01,756 org.fgq.study.log4j.Log4jFilter.doFilterInternal(Log4jFilter.java:59)ogger-ERROR - - set eventid:000010x1489116001756

2、
Request URL:http://localhost:8084/spmvc/mv/mvc/time?id=1
Request Method:GET
Status Code:200 OK
Remote Address:[::1]:8084

Response Headers
Content-Language:zh-CN
Content-Type:text/html;charset=utf-8
Date:Fri, 10 Mar 2017 03:21:02 GMT
Server:Apache-Coyote/1.1
Transfer-Encoding:chunked

Request Headers
Accept:*/*
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:zh-CN,zh;q=0.8
Connection:keep-alive
Cookie:eryewrhuewr
eventsign:eventsignOfQequest

服务器端日志：
2017-03-10 11:21:02,378 org.fgq.study.log4j.Log4jFilter.doFilterInternal(Log4jFilter.java:62)ogger-ERROR - - get eventid from request:eventsignOfQequest
2017-03-10 11:21:02,555 org.fgq.study.controller.TimeController.ShowTime(TimeController.java:34)ogger- WARN - 000010xeventsignOfQequest - get eventid:eventsignOfQequest, send request to other sub system ,and with the eventid!

返回内容：the eventsign is : eventsignOfQequest
参考： https://logback.qos.ch/manual/mdc.html

​​http://www.slf4j.org/manual.html​​

The Simple Logging Facade for Java (SLF4J) serves as a simple facade or abstraction for various logging frameworks, such as java.util.logging, logback and log4j. SLF4J allows the end-user to plug in the desired logging framework at deploymentonly a single mandatory dependency, namelyslf4j-api-1.7.7.jar.

SINCE 1.6.0 If no binding is found on the class path, then SLF4J will default to a no-operation implementation.

SINCE 1.7.0 ​​Logger​​​ interface now offer variants accepting​​varargs​​​ ​​Object[]​​​. This change implies that SLF4J requires JDK 1.5 or later. Under the hood the Java compiler transforms the varargs part in methods into ​​Object[]​​. Thus, the Logger interface generated by the compiler is indistinguishable in 1.7.x from its 1.6.x counterpart. It follows that SLF4J version 1.7.x is totally 100% no-ifs-or-buts compatible with SLF4J version 1.6.x.

SINCE 1.7.5users are highly encouraged to migrate to SLF4J 1.7.5 or later.

Hello World

As customary in programming tradition, here is an example illustrating the simplest way to output "Hello world" using SLF4J. It begins by getting a logger with the name "HelloWorld". This logger is in turn used to log the message "Hello World".

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloWorld {
  public static void main(String[] args) {
    Logger logger = LoggerFactory.getLogger(HelloWorld.class);
    logger.info("Hello World");
  }
}

To run this example, you first need to ​​download the slf4j distribution​​, and then to unpack it. Once that is done, add the file slf4j-api-1.7.7.jar to your class path.

Compiling and running HelloWorld will result in the following output being printed on the console.

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

This warning is printed because no slf4j binding could be found on your class path.

The warning will disappear as soon as you add a ​​binding​​ slf4j-simple-1.7.7.jar so that your class path contains:

• slf4j-api-1.7.7.jar
• slf4j-simple-1.7.7.jar

Compiling and running HelloWorld will now result in the following output on the console.

0 [main] INFO HelloWorld - Hello World

Typical usage pattern

The sample code below illustrates the typical usage pattern for SLF4J. Note the use of {}-placeholders on line 15. See the question ​​"What is the fastest way of logging?"​​ in the FAQ for more details.

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class Wombat {
 
  final Logger logger = LoggerFactory.getLogger(Wombat.class);
  Integer t;
  Integer oldT;

  public void setTemperature(Integer temperature) {
   
    oldT = t;        
    t = temperature;

    logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);

    if(temperature.intValue() > 50) {
      logger.info("Temperature has risen above 50 degrees.");
    }
  }
}

Binding with a logging framework at deployment time

As mentioned previously, SLF4J supports various logging frameworks. The SLF4J distribution ships with several jar files referred to as "SLF4J bindings", with each binding corresponding to a supported framework.

slf4j-log4j12-1.7.7.jar

Binding for ​​log4j version 1.2​​, a widely used logging framework. You also need to place log4j.jar on your class path.

slf4j-jdk14-1.7.7.jar

Binding for java.util.logging, also referred to as JDK 1.4 logging

slf4j-nop-1.7.7.jar

Binding for ​​NOP​​, silently discarding all logging.

slf4j-simple-1.7.7.jar

Binding for ​​Simple ​​implementation, which outputs all events to System.err. Only messages of level INFO and higher are printed. This binding may be useful in the context of small applications.

slf4j-jcl-1.7.7.jar

Binding for ​​Jakarta Commons Logging​​. This binding will delegate all SLF4J logging to JCL.

logback-classic-1.0.13.jar (requires logback-core-1.0.13.jar)

NATIVE IMPLEMENTATION ​​logback​​implements SLF4J natively. Logback's​​ch.qos.logback.classic.Logger​​​ class is a direct implementation of SLF4J's​​org.slf4j.Logger​​zero memory and computational overhead.

To switch logging frameworks, just replace slf4j bindings on your class path. For example, to switch from java.util.logging to log4j, just replace slf4j-jdk14-1.7.7.jar with slf4j-log4j12-1.7.7.jar.

SLF4J does not rely on any special class loader machinery. In fact, each SLF4J binding is hardwired at compile time slf4j-api-1.7.7.jar, you simply drop one and only one binding of your choice onto the appropriate class path location. Do not place more than one binding on your class path. Here is a graphical illustration of the general idea.

​​

The SLF4J interfaces and their various adapters are extremely simple. Most developers familiar with the Java language should be able to read and fully understand the code in less than one hour. No knowledge of class loaders is necessary as SLF4J does not make use nor does it directly access any class loaders. As a consequence, SLF4J suffers from none of the class loader problems or memory leaks observed with Jakarta Commons Logging (JCL).

Given the simplicity of the SLF4J interfaces and its deployment model, developers of new logging frameworks should find it very easy to write SLF4J bindings.

Libraries

Authors of widely-distributed components and libraries may code against the SLF4J interface in order to avoid imposing an logging framework on their end-user. Thus, the end-user may choose the desired logging framework at deployment time by inserting the corresponding slf4j binding on the classpath, which may be changed later by replacing an existing binding with another on the class path and restarting the application. This approach has proven to be simple and very robust.

As of SLF4J version 1.6.0, if no binding is found on the class path, then slf4j-api will default to a no-operation implementation discarding all log requests. Thus, instead of throwing a ​​NoClassDefFoundError​​​ ​​org.slf4j.impl.StaticLoggerBinder​​class is missing, SLF4J version 1.6.0 and later will emit a single warning message about the absence of a binding and proceed to discard all log requests without further protest. For example, let Wombat be some biology-related framework depending on SLF4J for logging. In order to avoid imposing a logging framework on the end-user, Wombat's distribution includes slf4j-api.jar but no binding. Even in the absence of any SLF4J binding on the class path, Wombat's distribution will still work out-of-the-box, and without requiring the end-user to download a binding from SLF4J's web-site. Only when the end-user decides to enable logging will she need to install the SLF4J binding corresponding to the logging framework chosen by her.

BASIC RULE Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a transitive dependency on a specific binding, that binding is imposed on the end-user negating the purpose of SLF4J. Note that declaring a non-transitive dependency on a binding, for example for testing, does not affect the end-user.

SLF4J usage in embedded components is also discussed in the FAQ in relation with ​​logging configuration​​​, ​​dependency reduction​​​ ​​testing​​.

Declaring project dependencies for logging

Given Maven's transitive dependency rules, for "regular" projects (not libraries or frameworks) declaring logging dependencies can be accomplished with a single dependency declaration.

LOGBACK-CLASSIC pom.xml logback-classic-1.0.13.jar, this will pull slf4j-api-1.7.7.jar logback-core-1.0.13.jar logback-core-1.0.13 slf4j-api-1.7.7.jar is not wrong and may be necessary to impose the correct version of said artifacts by virtue of Maven's "nearest definition" dependency mediation rule.

<dependency> 
  <groupId>ch.qos.logback</groupId>
  <artifactId>logback-classic</artifactId>
  <version>1.0.13</version>
</dependency>

LOG4J pom.xml slf4j-log4j12-1.7.7.jar, this will pull slf4j-api-1.7.7.jar log4j-1.2.17.jar log4j-1.2.17.jar slf4j-api-1.7.7.jar is not wrong and may be necessary to impose the correct version of said artifacts by virtue of Maven's "nearest definition" dependency mediation rule.

<dependency> 
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
  <version>1.7.7</version>
</dependency>

JAVA.UTIL.LOGGING If you wish to use java.util.logging as the underlying logging framework, all you need to do is to declare "org.slf4j:slf4j-jdk14" as a dependency in yourpom.xml slf4j-jdk14-1.7.7.jar, this will pull slf4j-api-1.7.7.jar slf4j-api-1.7.7.jar is not wrong and may be necessary to impose the correct version of said artifact by virtue of Maven's "nearest definition" dependency mediation rule.

<dependency> 
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-jdk14</artifactId>
  <version>1.7.7</version>
</dependency>

Binary compatibility

An SLF4J binding designates an artifact such as slf4j-jdk14.jar slf4j-log4j12.jar used tobind slf4j to an underlying logging framework, say, java.util.logging and respectively log4j.

From the client's perspective all versions of slf4j-api are compatible. Client code compiled with slf4j-api-N.jar will run perfectly fine with slf4j-api-M.jar for any N and M. You only need to ensure that the version of your binding matches that of the slf4j-api.jar. You do not have to worry about the version of slf4j-api.jar used by a given dependency in your project.

Mixing different versions of slf4j-api.jar and SLF4J binding can cause problems. For example, if you are using slf4j-api-1.7.7.jar, then you should also use slf4j-simple-1.7.7.jar, using slf4j-simple-1.5.5.jar will not work.

However, from the client's perspective all versions of slf4j-api are compatible. Client code compiled with slf4j-api-N.jar slf4j-api-M.jar slf4j-api.jar, and as long as the version of slf4j-api.jar and its binding match, you should be fine.

At initialization time, if SLF4J suspects that there may be an slf4j-api vs. binding version mismatch problem, it will emit a warning about the suspected mismatch.

Consolidate logging via SLF4J

Often times, a given project will depend on various components which rely on logging APIs other than SLF4J. It is common to find projects depending on a combination of JCL, java.util.logging, log4j and SLF4J. It then becomes desirable to consolidate logging through a single channel. SLF4J caters for this common use-case by providing bridging modules for JCL, java.util.logging and log4j. For more details, please refer to the page on​​Bridging legacy APIs​​.

Mapped Diagnostic Context (MDC) support

"Mapped Diagnostic Context" is essentially a map maintained by the logging framework where the application code provides key-value pairs which can then be inserted by the logging framework in log messages. MDC data can also be highly helpful in filtering messages or triggering certain actions.

SLF4J supports MDC, or mapped diagnostic context. If the underlying logging framework offers MDC functionality, then SLF4J will delegate to the underlying framework's MDC. Note that at this time, only log4j and logback offer MDC functionality. If the underlying framework does not offer MDC, for example java.util.logging, then SLF4J will still store MDC data but the information therein will need to be retrieved by custom user code.

Thus, as a SLF4J user, you can take advantage of MDC information in the presence of log4j or logback, but without forcing these logging frameworks upon your users as dependencies.

For more information on MDC please see the ​​chapter on MDC​​ in the logback manual.

Executive summary