|SLF4J distribution changed in 3.7.x [message #1772292]
||Thu, 07 September 2017 16:20
| Nikolas Falco
Registered: September 2017
Hi, I'm updating our Virgo Tomcat Server 3.6.4 to 3.7.2. We noticed a change in the distribution of the SFL4J libraries.|
In 3.6.4 is distributed SLF4J with api, JUL, JCL and LOG4J extender. So that bundles that import java and apache loggers are redirected on SLF4J that logs delegating to an installed binder (logback).
The name of jar are in P2 form <bundle symbolic name>.<version with timestamp>.jar
- org.slf4j.jcl_1.7.2.v20121108-1250 (extender)
- org.slf4j.jul_1.7.2.v20121108-1250 (extender)
- org.slf4j.log4j_1.7.2.v20130115-1340 (extender)
- org.slf4j.nop_1.7.2.v201212060727 (binder)
- ch.qos.logback.slf4j_1.0.7.v20121108-1250 (binder)
The virgo 3.7.2 distribuites SLF4J with api and JUL extenders. So only bundles that import java loggers is redirect on SLF4J that delegates to one of the installed binder (JUL, LOG4J and LOGBACK).
The name of jar are in groovy form (maybe, are not maven)
- slf4j_jcl-1.7.25 (binder)
- slf4j_log4j12-1.7.25 (binder)
- jul_to-slf4j-1.7.25 (extender)
- ch.qos.logback.classic_1.2.3 (binder)
Now the question is: Why the centralisation to SLF4J (that redirect logs on a single implementation) was removed?
What happen if a third party library logs to log4j ? Where is redirect it's log since log4j is not configured.
Maybe some changes in the compilation system led to the mistake of the JCL and LOG4J binders instead of the extender.
[Updated on: Fri, 08 September 2017 13:29]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.01657 seconds