SLF4J WARN messages on start-up
SlimeDog opened this issue ยท 10 comments
Versions
>we version
[08:20:27] [Server thread/INFO]: WorldEdit version 7.3.0-SNAPSHOT
[08:20:27] [Server thread/INFO]: https://github.com/EngineHub/WorldEdit/
[08:20:27] [Server thread/INFO]: ------------------ Platforms ------------------
[08:20:27] [Server thread/INFO]: * Bukkit-Official(7.3.0-SNAPSHOT+5669-2c7ac3d)
[08:20:27] [Server thread/INFO]: ---------------- Capabilities ----------------
[08:20:27] [Server thread/INFO]: GAME_HOOKS: Bukkit-Official
[08:20:27] [Server thread/INFO]: CONFIGURATION: Bukkit-Official
[08:20:27] [Server thread/INFO]: USER_COMMANDS: Bukkit-Official
[08:20:27] [Server thread/INFO]: PERMISSIONS: Bukkit-Official
[08:20:27] [Server thread/INFO]: WORLDEDIT_CUI: Bukkit-Official
[08:20:27] [Server thread/INFO]: WORLD_EDITING: Bukkit-Official
>version
[08:20:37] [Server thread/INFO]: This server is running CraftBukkit version 3012-Spigot-73fb609-0cd8f19 (MC: 1.16.5) (Implementing API version 1.16.5-R0.1-SNAPSHOT)
[08:20:37] [Server thread/INFO]: You are running the latest version
Describe the bug
On server start-up
[08:16:15] [Server thread/WARN]: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
[08:16:15] [Server thread/WARN]: SLF4J: Defaulting to no-operation (NOP) logger implementation
[08:16:15] [Server thread/WARN]: SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
To Reproduce
- Update WE from 7.3.0-SNAPSHOT+5647-476342a to 7.3.0-SNAPSHOT+5669-2c7ac3d; no other changes
- Start server
- Review log
Expected behavior
Same as previous versions.
I test dev releases of many plugins, on a test server. I understand and accept the caveat, and I find a lot of bugs.
It seems that SLF4J is missing in b5669, as suggested by the WARN messages:
% grep org.slf4j plugins/WorldEdit-bukkit-7.3.0-b5669.jar
%
Compare with b5647, and many other plugins that include SLF4J without producing warnings:
% grep org.slf4j plugins/*.jar
Binary file plugins/CombatLogX-10.3.8.3.jar matches
Binary file plugins/HelpTickets-3.3.jar matches
Binary file plugins/ItemJoin-5.2.0-b674.jar matches
Binary file plugins/LagMonitor-1.17.1-b165.jar matches
Binary file plugins/Plan-5.2-b1063.jar matches
Binary file plugins/Quests-4.0.0-rc.4-b215.jar matches
Binary file plugins/V10Lift-0.7.1.jar matches
Binary file plugins/WorldEdit-bukkit-7.3.0-b5647.jar matches
%
Agreed that it's been used for ages, but the WARN messages were not previously produced.
I didn't see them in 5647 or any previous versions. I print the WARN messages on every start-up. Same issue on Paper as well, BTW.
In any event, is the binding meant to be missing? If so, what is the purpose of SLF4J?
Failed to load class org.slf4j.impl.StaticLoggerBinder
This warning message is reported when the org.slf4j.impl.StaticLoggerBinder class could not be loaded into memory. This happens when no appropriate SLF4J binding could be found on the class path. Placing one (and only one) of slf4j-nop.jar slf4j-simple.jar, slf4j-log4j12.jar, slf4j-jdk14.jar or logback-classic.jar on the class path should solve the problem.
Note that slf4j-api versions 2.0.x and later use the ServiceLoader mechanism. Backends such as logback 1.3 and later which target slf4j-api 2.x, do not ship with org.slf4j.impl.StaticLoggerBinder. If you place a logging backend which targets slf4j-api 2.0.x, you need slf4j-api-2.x.jar on the classpath. See also relevant faq entry.
SINCE 1.6.0 As of SLF4J version 1.6, in the absence of a binding, SLF4J will default to a no-operation (NOP) logger implementation.
If you are responsible for packaging an application and do not care about logging, then placing slf4j-nop.jar on the class path of your application will get rid of this warning message. Note that embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding but only depend on slf4j-api. When a library declares a compile-time dependency on a SLF4J binding, it imposes that binding on the end-user, thus negating SLF4J's purpose.
dunno, but i've been seeing this for ages and it's definitely not specific to 7.3 (which is not the current release branch btw)
possibly something related to #1651 ? would need octy to weigh in, not sure why this might have changed or why it might have occurred earlier in my dev setup.