Logback日志框架中的继承机制详解

在Logback框架中，logger的继承机制是基于层级结构（hierarchical context）工作的。每个logger都被分配一个名称，这个名称可以看作是一个路径或目录结构，从而形成了一个逻辑上的树状结构。这种结构使得日志记录具有很强的灵活性和可控性。

Logger 层级结构

1. 根Logger (root logger)：

   • 根logger是所有logger的祖先，它没有名称，通常通过<root>标签来配置。
   • 每个应用程序至少有一个root logger，并且它是唯一不需要显式命名的logger。
   • 如果某个logger没有定义特定的日志级别，它会继承root logger的日志级别。

2. 命名Logger：

   • 除了root logger之外的所有logger都是命名logger，它们的名字通常是类、包或者自定义的字符串。
   • 命名logger按照点号（.）分隔成多个部分，例如com.example.service，其中com是顶级节点，example是com的子节点，service是example的子节点。

继承规则

• 日志级别继承：

  • 如果一个logger没有显式设置自己的日志级别，那么它将继承其最近的父级logger的日志级别。最终，如果追溯到root logger，而root logger也没有设置日志级别，则默认使用DEBUG级别（具体取决于框架版本和配置）。

• Appender继承：

  • 默认情况下（即additivity=true），一个logger的日志事件不仅会被自己配置的appender处理，还会被传递给它的所有祖先logger，直到root logger，由这些祖先logger配置的appender再次处理。
  • 如果一个logger设置了additivity=false，那么它的日志事件只会被自己配置的appender处理，不会传递给任何祖先logger。

示例

假设你有如下的logback配置：

<configuration>
    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <!-- appender configuration -->
    </appender>

    <root level="INFO">
        <appender-ref ref="FILE"/>
    </root>

    <logger name="com.example" level="DEBUG"/>
    
    <logger name="com.example.service" level="TRACE" additivity="false">
        <appender-ref ref="FILE"/>
    </logger>
</configuration>

在这个例子中：

• root logger的日志级别为INFO，并且有一个FILE类型的appender。
• com.example logger的日志级别为DEBUG，但是它没有自己的appender，所以它会继承root logger的appender。
• com.example.service logger的日志级别为TRACE，并且它有自己的appender，同时它的additivity属性被设置为false，这意味着它的日志信息不会被传递给com.example或root logger，只会在它自己的appender中处理。

通过这样的层级结构和继承规则，Logback允许开发者精细地控制不同包、类或组件的日志输出行为，确保应用的日志系统既灵活又高效。