Muss slf4j trotzdem gezwungen werden, einen bestimmten Protokollanbieter zu verwenden (Rückmeldung in meinem Fall)? Wie in ihren Dokumenten:

Auf dem Klassenpfad wurden mehrere Bindungen gefunden

Die SLF4J-API soll jeweils nur an ein einziges zugrunde liegendes Protokollierungsframework gebunden sein. Wenn mehr als eine Bindung im Klassenpfad vorhanden ist, gibt SLF4J eine Warnung aus, in der der Speicherort dieser Bindungen aufgeführt ist. Wenn im Klassenpfad mehrere Bindungen verfügbar sind, wählen Sie nur eine Bindung aus, die Sie verwenden möchten, und entfernen Sie die anderen Bindungen. Wenn Sie beispielsweise sowohl slf4j-> simple-1.6.6.jar als auch slf4j-nop-1.6.6.jar im Klassenpfad haben und die Bindung nop (> no-operation) verwenden möchten, entfernen Sie slf4j- simple-1.6.6.jar aus dem Klassenpfad. Wenn es nicht möglich ist, die überflüssigen Bindungen zu entfernen, bindet SLF4J weiterhin mit einem Protokollierungsframework / einer Protokollierungsimplementierung. Ab Version 1.6.6 nennt SLF4J die Framework- / Implementierungsklasse, an die es gebunden ist.

HINWEIS Die Warnung von SLF4J ist nur eine Warnung.

In meinem Fall habe ichlog4j.jar, slf4j-log4j12.jar, log4j-over-slf4j.jar und alle Logback-Gläser im Klassenpfad. Ich weiß, dass es ein Fehler istslf4j-log4j12.jar undlog4j-over-slf4j.jar zusammen, aber mein projekt ist sehr groß und es ist nicht immer einfach, maven-abhängigkeit zu finden und auszuschließen. In diesem Fall hat slf4j sogar keine Warnung ausgegeben, da wir nur Logback-Konfigurationen verwenden. Ich brauchte einen Tag, um diese Glas-Hölle zu verstehen.

Alles, was ich möchte, ist, slf4j zu zwingen, das Logback über das JVM-Argument zu verwenden, damit es Warnungen ausgeben und Gläser in Zukunft ausschließen kann.