Springboot启动异常日志被吞掉

项目中使用了springboot2.0.4,并集成了elasticsearch、dubbo等组件。在更新了创库代码后,发现突然程序启动不了,总是启动后tomcat自动关闭,日志信息如下: image_1.png

很纳闷 :-(,任何异常日志都没有,出什么情况了?

第一感觉是程序有问题,更新了代码导致。可是本次更新的代码量有比较大,从源代码比对分析不靠谱,需要大量时间。另外源码有问题启动日志也应该要有报错信息。

是日志级别不对吗?

检查配置logging.level.root已经是INFO级别了,且没有其它级别控制。尝试将logging.level.root=debug,重启发现依然没有任何异常信息展现。

日志输出组件冲突了吗?

由于笔者之前有过log4j框架切换logback的经验,因此怀疑pom中引入的组件传递依赖了一些不需要的jar包,导致日志组件冲突。

检查pom文件发现:

  1. elasticsearch-rest-client-snifferdubbo组件传递依赖引入了common-logging组件。导致spring-jcl组件的org.apache.commons.logging.LogFactory没有被加载,而使用了common-logging中的org.apache.commons.logging.LogFactory类; 这是因为在JVM环境中存在同名的的class,类加载器根据加载顺序选择的。

  2. spring-jclLogFactory中,实现逻辑是如果log4j2jar包存在,这优先使用log4j2来记录日志、然后才是slf4j。而在common-loggingLogFactory中,实现逻辑是如果log4jjar包存在,优先采用log4j、然后采用jdk的util包中的logger记录。

  3. 在我们的启动环境中,我们采用通过spring-boot-starter-logging组件来输出日志,其默认采用的是slf4j-api来通过logback记录日志,log4j2组件是不存在的,于是springboot在启动时,因为类加载器的原因使用了common-loggingLogFactory,又因为dubbozookeeperzkclient引入了log4j组件,导致springboot启动时的部分日志输出到了log4j,因此异常被吃掉了。

解决办法

在依赖的“elasticsearch-rest-client-sniffer”、“dubbo”组件中排除掉对common-logging的依赖。

<dependency>
    <groupId>org.elasticsearch.client</groupId>
    <artifactId>elasticsearch-rest-client-sniffer</artifactId>
    <version>${elasticsearch.version}</version>
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>dubbo</artifactId>
    <version>${dubbo.version}</version>
    <exclusions>
        <exclusion>
            <groupId>commons-logging</groupId>
            <artifactId>commons-logging</artifactId>
        </exclusion>
    </exclusions>
</dependency>

解决后重启程序,终于看到了异常原因: image_2.jpg


   转载规则


《Springboot启动异常日志被吞掉》 Angus_Lu 采用 知识共享署名 4.0 国际许可协议 进行许可。
 上一篇
基于SpringBoot快速发布SOAP接口 基于SpringBoot快速发布SOAP接口
WebService、SOAP、WSDL的简单回顾WebService是什么?WebService在的概念很容易引起误解,很多初级开发人员的认知WebService接口等同于Soap接口,其实这是一种错误的认知。WebService是相对于
2019-01-02 14:22:35
下一篇 
HornetQ引发的一次生产环境故障 HornetQ引发的一次生产环境故障
前段时间生产环境遇到一次故障,最终分析原因是HornetQ队列空间满造成。HornetQ是JBoss可能旗下的一款MQ产品,现已捐献给了Apache的ActiveMQ。下面将本次故障分析分享给大家,因涉及产品的信息安全问题,本文隐去了某些敏
2018-09-03 20:46:34
  目录