Die Standardmethode zur Verwendung von SLF4J ist, dass es sich um das Hauptprotokollierungsframework handelt, das Sie verwenden. (Sie rufen Methoden auf, die innerhalb der slf4j-api definiert sind.) Sie verwendet wiederum eine "binding" wie slf4j-log4j12, die ihr sagt, wie mit dem "echten" Protokollierungs-Framework zu sprechen ist. Und dann müssen Sie auch das echte Protokollierungs-Framework auf Ihrem Klassenpfad haben, wie zum Beispiel "log4j" Version 1.2.
Einige neuere Logging-Bibliotheken, wie Logback, sind sowohl die „Bindung“ und der „realen“ Rahmen, also, wenn Sie verwenden möchten, dass als Logging-Framework, die Sie zusammen mit slf4j-api, nur logback-classic müssen, so ist es zwei Bibliotheken statt drei.
Die verwirrenden "über" und "zu" -Bibliotheken existieren als eine Möglichkeit, mit der Realität umzugehen, dass Sie wahrscheinlich auf Bibliotheken angewiesen sind, die sich anders als die für Ihre Anwendung ausgewählte Anmeldung anmelden möchten, aber es ist schön, alles in einen Rahmen zu lenken. Wenn Sie also SLF4J und Logback verwenden, aber auf eine Bibliothek angewiesen sind, die mit Log4j 1.2 loggt, möchten Sie die log4j-over-slf4j library einbeziehen, die alle Log4j-Aufrufe innerhalb beliebiger Bibliotheken in Ihrer Anwendung abfängt und in sie übersetzt stattdessen von SLF4J angemeldet werden. Umgekehrt, wenn Sie sich direkt mit Log4j 1.2 (ohne SLF4J) anmelden und eine Bibliothek aufrufen müssen, die SLF4J verwendet, sollten Sie die Bibliothek slf4j-log4j12 einschließen, um diese Aufrufe abzufangen und sie für Sie in Log4j zu übersetzen. Es gibt eine Vielzahl dieser Arten von Bibliotheken, die jeweils von einem bestimmten Protokollierungsrahmen zu einem anderen abfangen und übersetzen.
Aber Ihre Frage lautete: "Also, welche Kombination und Version sollte ich wählen?", Was ziemlich weit gefasst ist, da wir uns nicht sicher sind, was Sie versuchen zu tun. Die Auswahl eines Protokollierungs-Frameworks ist wie bei jeder anderen Technologie-Framework-Entscheidung, basierend auf vielen Faktoren wie der Vertrautheit mit dem Entwickler, den zu verwendenden Systemen und, falls vorhanden, Code oder Standards, mit denen man konsistent bleiben möchte.Also, ich werde versuchen, zu viel bekommen in diesen Auswahlprozess zu vermeiden und beantworten Ihre Frage, wie Maven einzurichten SLF4J als Logging-Framework zu verwenden, unterstützt von Log4j version 2:
- eine Abhängigkeit hinzu die aktuelle Version von slf4j-api
eine Abhängigkeit für Log4j 2 und seine SLF4J Bindung (von https://logging.apache.org/log4j/2.x/maven-artifacts.html) hinzufügen:
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.6.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.6.1</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
<version>2.6.1</version>
</dependency>
</dependencies>
- Verwenden Sie
<dependencyManagement> Abschnitte in Ihrem POM, um sicherzustellen, dass alle Ihre Abhängigkeiten dieselbe Version Ihres Protokollierungsframeworks verwenden. (Zum Beispiel enthalten viele Bibliotheken slf4j-api als Abhängigkeit, aber sie können jeweils eine andere Version verwenden.) Im Allgemeinen behalten Logger-Frameworks eine gute Kompatibilität zwischen den Versionen bei, sodass Sie im Allgemeinen alle bereitgestellten Abhängigkeitsversionen mit der (normalerweise neueren) Version überschreiben möchten das du benutzt.
- Wenn Sie Bibliotheken haben, die ein anderes Protokollierungsframework verwenden, verwenden Sie die entsprechende Interceptorbridge, um die Protokollierung umzuleiten, entweder , die direkt zu Log4Jj2 umleitet, oder eine from SLF4J, die zu SLF4J umleitet, was dann sein wird Weiter zu Log4j. (Obwohl es zweimal Umleitung zu tun scheint, könnte es die Dinge einfacher machen, wenn Sie SLF4J behalten, aber irgendwann zu einem anderen "echten" Logging-Framework wechseln. Vielleicht.) Zum Beispiel, wenn Sie eine Bibliothek haben, die Commons-Logging verwendet , möchten Sie stattdessen
jcl-over-slf4j einschließen.
- Verwenden Sie außerdem die -Regeln
bannedDependencies, um sicherzustellen, dass Sie alle nicht verwendeten Protokollframeworks ausschließen, die von den Bibliotheken, auf die Sie angewiesen sind, in Ihr Projekt eingefügt werden sollen. Das heißt, für dieses Beispiel, das ich von einer Bibliothek gegeben habe, die Sie verwenden, die commons-logging verwendet, müssen Sie <exclude>commons-logging aus dieser Bibliotheksabhängigkeit, und fügen Sie es zu Ihrer bannedDependencies Liste, um sicherzustellen, dass Sie es nicht versehentlich wieder aus einer anderen Bibliothek erhalten . Andernfalls haben Sie sowohl das "echte" Commons-Logging als auch Ihre gefälschte Bridge (die die Schnittstelle emuliert und in Ihr echtes Logging-Framework übersetzt) auf dem Classpath und werden in Schwierigkeiten geraten.
Ich hoffe, dass Übersicht hilft. Hinweis: Ich habe noch nicht versucht, Log4j 2 in irgend einem Programm auszuführen, und habe diese Abhängigkeiten nur aus ihrer Dokumentation abgeleitet. Testen Sie auf jeden Fall, dass alles so funktioniert, wie Sie es erwarten.
# 3 sieht wie die Antwort aus, nach der Sie suchen: Sie benötigen die API (slf4j-api-VERSION.jar) und das jar, das zu dem zu verwendenden Protokollierungs-Framework passt (slf4j-log4j12-VERSION.jar). Die beste Antwort sollte unter http://www.slf4j.org/manual.html sein. –
Was genau willst du? die log4j api mit einer slf4j-Implementierung oder die (häufigste) slf4j-api mit einer log4j-Implementierung –