2.3.2 Spring 内部日志机制(logging)
2.3.2 Spring 内部日志机制(logging)
流光韶逝 发表于1年前
2.3.2 Spring 内部日志机制(logging)
  • 发表于 1年前
  • 阅读 18
  • 收藏 0
  • 点赞 0
  • 评论 0

腾讯云 新注册用户 域名抢购1元起>>>   

摘要: spring 日志依赖的简介及建议;包括 commons-logging, log4J,logback,SLF4j等主流的日志框架和管理工具;本文大部分是原文翻译,少部分为个人见解.
  • 原文地址日志模块

  • 日志是spring一个非常重要的依赖,因为:a.它是唯一强制依赖,B.每个人都希望看到他们使用工具的输出;c.spring整合大量其他工具,它们也需要日志依赖.应用开发者的一个重要目标就是:在整个应用的核心区域可以对日志进行统一配置,包括所有额外组件. 由于有很多日志框架,曾经使这个目标变得更困难; spring的强制日志依赖是Jakarta Commons Logging API(JCL).我们编译JCL,我们也使JCL 日志对其他继承了spring框架的类可见.使用相同的日志类库对用户来说非常重要:保持向后兼容性,可以使spring的应用集成更加容易.我们这么做的目的是为了让spring的一个模块明确依赖commons-logging(JCL的规范实现),并使其他模块在编译期间依赖该模块; 例如你使用了Maven并好奇你从哪里得到commons-logging依赖,它将从spring特别是从叫spring-core的核心模块获得; 使用commons-logging最便捷的地方是你不需要其他东西来使你的应用工作.它有一组运行时发现算法,可以在classpath下明显的地方查找日志框架,并使用它认为合适的那个(或者你可以告诉它你需要那个).如果没有发现其他日志框架,它就会从JDK中使用那些更漂亮些的日志(java.util.logging或简化的JUL).你应该发现你的spring项目可以在大多数没有控制台的环境下运行并日志记录,而且这很重要;

    ###不要使用Commons Logging 不幸的是,commons-logging的可以方便最终用户的运行期间发现算法是有问题的.如果时间能倒流,我们能重新开发spring,那就让我们重新选一个不同的日志依赖吧.这个首选项可以是java简单日志门面(Simple Logging Facade for Java,SLF4J),它同样可以和spring一起运行在其他工具里; 这里有两种基本的方式抛弃commons-logging: 1.移除(exclude)spring-core模块的依赖(它是明确需要commons-logging依赖的模块); 2.将特定需要commons-logging依赖的地方用一个空jar来替换类库(更多细节可以在 SLF4J FAQ 中查找);移除commons-logging,将这些添加到你的maven依赖管理区域;

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>4.3.1.RELEASE</version>
        <exclusions>
            <exclusion>
                <groupId>commons-logging</groupId>
                <artifactId>commons-logging</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
</dependencies>

如果只这样的话项目就会报错,因为它的classpath现在缺少JCL API的实现;你可以提供一个新的日志 模块来修复它;

使用SLF4J

SLF4J是一个更简洁的依赖,它比common-logging更高效,因为它使用了运行时绑定来代替后者的运行时发现算法,这样更好的进行日志框架整合.这意味着你必须要明确的明白运行时发生了什么,或对其进行相应的声明或配置.SLF4J支持许多common logging框架,所以你可以选择一个你使用过的,对其绑定后进行配置和管理; SLF4J提供了对许多日志框架的绑定,包括JCL,同时它也做反向操作:桥接其他日志框架和它本身.所以使用spring的SLF4J你需要将commons-logging 依赖替换为SLF4-JCL桥接.你做完之后,spring的日志调用将转化为SLF4J API,只要你的项目中其他类库使用API,然后你就可以只在一个地方去配置和管理日志; 一个更通用的选项是将SLF4J桥联到spring,然后将SLF4J绑定到Log4J中.你需要提供四个依赖(还要移除已存在的commons-logging):有bridge(桥联),SLF4J API,Log4J框架的绑定,log4j自身的实现.在Maven中可能这么做

<dependencies>
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-core</artifactId>
        <version>4.3.1.RELEASE</version>
        <exclusions>
            <exclusion>
                <groupId>commons-logging</groupId>
                <artifactId>commons-logging</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>jcl-over-slf4j</artifactId>
        <version>1.5.8</version>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>1.5.8</version>
    </dependency>
    <dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-log4j12</artifactId>
        <version>1.5.8</version>
    </dependency>
    <dependency>
        <groupId>log4j</groupId>
        <artifactId>log4j</artifactId>
        <version>1.2.14</version>
    </dependency>
</dependencies>
```	

这看起来可能要用很多依赖才能使用一些日志.虽如此,但它是可选择的;它在面对类加载器的问题时比普通的common-logging框架做的更好,尤其是你使用一些严格的容器,例如OSGI平台(如电网的sg-uap).据说另一显著优势是:它们在编译期间完成了绑定而非运行期;
   ###使用LogBack

   对于SLF4J的使用者而言,有一个更通用的选择,那就是使用Logback [logback](http://logback.qos.ch/) ,这将使用更少的步骤和更少的依赖.这会去掉其他的绑定步骤,因为Logback直接实现了SLF4J,这样你就只需要两个依赖就可以了而不是四个(只用jcl-over-slf4j和logback).还有,为了保持slf4J的版本一致性,你需要从其他非spring依赖中移除slf4j-api依赖;

  ###使用log4j
   许多人使用Log4J作为日志框架用来配置和管理.它非常高效而且容易建立;实际上我们创建和检测spring时在运行时就使用他(log4J).Spring也为启动和配置Log4J提供了一些支持,所以在许多模块中log4J可作为编译期可选择的依赖;
       要想将log4J和默认的JCL依赖(commons-logging)一起使用,你需要将log4J加入到classpath中,并提供一个配置文件(log4j.properties或者log4j.xml在根路径下).对于maven用户来说,可以如此配置声明:

<dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>4.3.1.RELEASE</version> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.14</version> </dependency> </dependencies>

此处为简单的log4j.properties文件内容

```	    	
log4j.rootCategory=INFO, stdout

log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %t %c{2}:%L - %m%n

log4j.category.org.springframework.beans.factory=DEBUG
```	    
###运行容器中的原生JCL(Runtime Containers with Native JCL)
 许多人在一个提供了JCL实现的容器中运行项目;	IBM的Websphere Application Server(WAS)是一个典型;这经常出问题,还没有啥银弹方案,简单的移除你项目中的commons-logging在大部分场景是没有用的
    要清楚明白:这个问题无关JCL本身,甚至无关commons-logging;也不是绑定commons-logging到其他架构(如 log4J)中. 它会失败是因为我们使用的是1.1版本,而这些容器中使用的1.0的版本,这样他们就会改变commons-logging的运行发现算法.spring并没有使用JCL API的其他无用部分,所以无法破解,然当你的spring或项目尝试使用其他日志时,你就会发现对Log4J的绑定就不起作用了;
    在WAS环境下,最简单的事就是反转类加载器的层次,这样我们就可以用应用本身来管理JCL依赖,而不是用WAS容器.然该选项不总是打开的,但是公共社区应该还有其的可用方法的建议,而且你的具体操作取决于容器的确切版本和其功能集;
共有 人打赏支持
粉丝 18
博文 87
码字总数 124633
×
流光韶逝
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: