Coding With Fun
Home Docker Django Node.js Articles Python pip guide FAQ Policy

MyBatis log


May 16, 2021 MyBatis


Table of contents


Logging

Mybatis' built-in log factory provides log functionality with several tools for specific log implementations:

  • SLF4J
  • Apache Commons Logging
  • Log4j 2
  • Log4j
  • JDK logging

Which log implementation tool to select is determined by MyBatis' built-in log factory. I t uses the first find (in the order listed above). If one is not found, the log feature is disabled.

Commons Logging, such as Tomcat and WebShpere, is already included in the classpath of many application servers, so MyBatis implements it as a specific log. I t's important to remember that. T his will mean that in an environment such as WebSphere, where WebSphere provides a private implementation of Commons Logging, your Log4J configuration will be ignored. T his is sad, how can MyBatis ignore your configuration? I n fact, since Commons Logging already exists, Log4J is naturally ignored in order of priority! However, if your app is deployed in an environment that contains Commons Logging and you want to use a different log framework, you can call one of the following methods as needed:

org.apache.ibatis.logging.LogFactory.useSlf4jLogging();
org.apache.ibatis.logging.LogFactory.useLog4JLogging();
org.apache.ibatis.logging.LogFactory.useJdkLogging();
org.apache.ibatis.logging.LogFactory.useCommonsLogging();
org.apache.ibatis.logging.LogFactory.useStdOutLogging();

If you do need to call one of the above methods, call it before all other MyBatis methods. I n addition, it makes sense to call the corresponding method only if it exists in the corresponding log implementation, otherwise MyBatis is ignored. If Log4J does not exist in your environment, and you call the appropriate method, MyBatis ignores the call and doesn't find the log implementation in the default lookup order.

Api introductions to SLF4J, Apache Commons Logging, Apache Log4J, and JDK Logging are beyond the scope of this document. H owever, the following example can be used as a quick start. For more information about these log frameworks, you can refer to the following links:

Logging Configuration

MyBatis can log packages, classes, namespaces, and fully qualified statements.

Depending on the log framework used, Log4J is an example. C onfiguring logs is simple: add a few profiles, such as log4j.properties, and then add a jar package, such as log4j.jar. Here are some concrete examples of two steps:

Step 1: Add a jar package for Log4J

Because of Log4J, make sure that the jar package that corresponds to the app is available. T o meet this, simply add the jar package to the app's classpath. Log4J's jar package can be downloaded from the link above.

Specifically, for web or enterprise applications, log4j.jar needs to be added to the WEB-INF/lib directory; -classpath

Step 2: Configure Log4J

Configuring Log4J is simple, for example, to log this mapper interface:

    package org.mybatis.example;
    public interface BlogMapper {
      @Select("SELECT * FROM blog WHERE id = #{id}")
      Blog selectBlog(int id);
    }

As long as you create a file named log4j.properties the details of the file are as follows:

    # Global logging configuration
    log4j.rootLogger=ERROR, stdout
    # MyBatis logging configuration...
    log4j.logger.org.mybatis.example.BlogMapper=TRACE
    # Console output...
    log4j.appender.stdout=org.apache.log4j.ConsoleAppender
    log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
    log4j.appender.stdout.layout.ConversionPattern=%5p [%t] - %m%n

With the above configuration added, Log4J logs the detailed execution of org.mybatis.example.BlogMapper and only logs error messages for other classes in the app.

You can also adjust logs from the entire mapper interface level to the statement level for more granular control. The following configuration selectBlog statements:

log4j.logger.org.mybatis.example.BlogMapper.selectBlog=TRACE

In contrast, logs can be logged for a set of mapper interfaces, as long as the log function is turned on on the package in which the capper interface is located:

    log4j.logger.org.mybatis.example=TRACE

What if some queries may return a large amount of data and just want to record the SQL statements they execute? F or this reason, the log level of the SQL sentence in Mybatis is set to DEBUG (FINE in JDK Logging) and the resulting log level is TRACE (FINE in JDK Logging). Therefore, you can do this by simply adjusting the log level to DEBUG:

    log4j.logger.org.mybatis.example=DEBUG

What if you want to log a mapper file like the one below instead of the mapper interface?

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
  PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
  "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="org.mybatis.example.BlogMapper">
  <select id="selectBlog" resultType="Blog">
    select * from Blog where id = #{id}
  </select>
</mapper>

For this file log, simply add logging to the namespace:

    log4j.logger.org.mybatis.example.BlogMapper=TRACE

Further, you can do this by logging specific statements:

log4j.logger.org.mybatis.example.BlogMapper.selectBlog=TRACE

See, there's no difference between the two configurations!

The log4j.properties is for the log format, which is beyond the scope of this document. F or more information about Log4J, please refer to Log4J's website. H owever, you can simply try to see what different configurations can have.