我的日志依赖项当前如下所示：
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-bom</artifactId>
<version>2.9.1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.25</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
</dependency>我注意到了 commons-logging.jar 因为某些原因还在我的课堂上。我是否应该排除这一点？这是否会引起任何问题？
到目前为止，我还没有注意到任何问题，但我仍然在想那个jar是否还会引起问题。
2条答案
按热度按时间fkaflof61#
是的，排除commons日志依赖项并添加log4j jcl桥：
slf4j api也是多余的，因为它已经是log4j-slf4j-impl绑定的可传递依赖项。
11dmarpk2#
存在使用
commons-logging. 如果它不存在，你会得到NoClassDefFoundErrors当他们试图登录时。如果有可能让那些人甚至不尝试使用依赖关系，那就不会有问题。不过，这种可能性不大。但是，如果他们使用
commons-logging但你用的是SLF4J，那就有问题了。他们在错误的地方登录（从你的Angular ）。这就是伐木桥的用武之地。它们实现了不同日志框架的公共api，但是将日志重定向到您正在使用的对象。为了
SLF4J有好几座桥（双向），所以commons-logging，你带进来jcl-over-slf4j. 图书馆会认为他们在使用commons-logging，当他们实际使用SLF4J（然后使用实际的日志实现，如logback）。很简单，嗯？；）