it-swarm.com.de

So verwenden Sie log4j 2.0 und slf4j und Commons Logging zusammen

Ich starte gerade eine neue Webapp (läuft auf Tomcat 6) Ich habe Komponenten, die slf4j verwenden, und Komponenten, die Commons Logging Verwenden. Ich habe vor, log4j 2.0 aus verschiedenen Gründen als Protokollimplementierung zu verwenden (hauptsächlich für die Appender: SocketAppender und SyslogAppender, aber auch wegen des geförderten Konfigurationsneuladens ohne Verlust von Protokollereignissen

Jetzt sind meine Fragen: - Auf welche Schnittstelle programmiere ich meine neuen Klassen? loag4j oder slf4j? oder sogar Commons Logging?

  • Was ist der bevorzugte Weg, um die Gläser einzusetzen? füge ich sie in meine Anwendung ein oder füge ich sie in die Tomcat-Bibliotheken ein?

  • welche Gläser muss ich bereitstellen? log4j (einschließlich slf4j- und commons-Bindungen), Commons-Protokollierung (slf4j-api-1.7.2.jar) und slf4j-api (slf4j-api-1.7.2.jar)

14
raudi

Auf welche Schnittstelle programmiere ich meine neuen Klassen? loag4j oder slf4j? 

Wenn Sie SLF4J verwenden, programmieren Sie diese Schnittstelle. Es bietet die größte Flexibilität für die zugrunde liegende Implementierung der Protokollierung. Das Ziel von slf4j ist es, eine Schnittstelle zu sein, auf die Sie programmieren können. Wenn Sie also in der Zukunft beispielsweise zu logback wechseln möchten, müssen Sie Ihren Code nicht erneut schreiben.

Was ist der bevorzugte Weg, um die Gläser einzusetzen? füge ich sie in meine Anwendung ein oder füge ich sie in die Tomcat-Bibliotheken ein?

Setze sie in deinen Krieg. 

Der einzige Grund (imo), JARs im Tomcat-Verzeichnis libs abzulegen, besteht darin, dass sie eine native Bibliothek laden müssen. Da es Ihnen in Java nicht möglich ist, dieselbe native Bibliothek aus zwei verschiedenen Classloadern zu laden, müssen Sie sie an einem gemeinsamen Ort ablegen. Das trifft hier aber nicht zu.

Einige Leute halten das lib-Verzeichnis für eine Möglichkeit, Speicherplatz zu sparen. Dies war möglicherweise gültig, wenn "Server-Klasse" -Maschinen über 1 GB RAM verfügten, dies ist jedoch nicht mehr der Fall. Das Vermeiden von lib bedeutet, dass Sie die meisten der schwer zu debuggenden Probleme beim Classloading vermeiden.

welche Gläser muss ich bereitstellen? 

  • slf4j-api ist die Basis-API
  • slf4j-log4j12 leitet die tatsächliche Protokollierung an Log4J weiter
  • jcl-over-slf4j fängt Commons Logging ab und leitet es über SLF4J (an Log4J) weiter
  • log4j wird Ihr physisches Protokollierungs-Framework sein

Ich gehe davon aus, dass Sie bereits eine Konfiguration für Log4J haben und/oder diese Konfiguration bequem schreiben können. Wenn nicht, und alles, was Ihnen wichtig ist, ist der Umgang mit Code, der intern Log4J verwendet, log4j-over-slf4j, der Log4J-Aufrufe abfängt. Dann müssen Sie ein Framework auswählen, z. B. Logback.

(Hinweis: Ich habe ursprünglich Links zu all diesen Paketen hinzugefügt, habe aber nicht genügend Wiederholungen, um sie zu veröffentlichen. Also hier ist ein einziger Link zum Maven-Repository mit allen hervorgehobenen SLF4J-Paketen.)

22
parsifal

Ich verwende slf4j mit log4j2 und verwende

slf4j-api-1.7.12.jar
log4j-api-2.2.jar
log4j-core-2.2.jar
log4j-slf4j-impl-2.2.jar
jcl-over-slf4j-1.7.12.jar(get rid of commons logging jars)

wenn auf Ihrem App-Server widersprüchliche Versionen vorhanden sind, müssen Sie möglicherweise einige herstellerspezifische Classloader-Einstellungen außer Kraft setzen

z.B. in weblogic 12 c habe ich dies in meiner weblogic.xml in src/main/webapp/WEB-INF

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app 
xmlns="http://xmlns.Oracle.com/weblogic/weblogic-web-app" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://Java.Sun.com/xml/ns/javaee http://Java.Sun.com/xml/ns/javaee/web-app_2_5.xsd 
http://xmlns.Oracle.com/weblogic/weblogic-web-app http://xmlns.Oracle.com/weblogic/weblogic-web-app/1.5/weblogic-web-app.xsd">
<container-descriptor>
    <prefer-application-packages>
        <package-name>org.Apache.log4j.*</package-name>
        <package-name>org.Apache.commons.logging.*</package-name>
        <package-name>org.Apache.commons.lang.*</package-name>
        <package-name>org.Apache.commons.io.*</package-name>
        <package-name>org.Apache.commons.collections4.*</package-name>
        <package-name>org.slf4j.*</package-name>
    </prefer-application-packages>
</container-descriptor>
<jsp-descriptor>
    <keepgenerated>true</keepgenerated>
    <debug>true</debug>
</jsp-descriptor>
<context-root>/cnfg</context-root>
</weblogic-web-app>
7
Kalpesh Soni

Bitte beachten Sie, dass ich Log4J 2.0 nicht verwendet habe, obwohl ich SLF4J mit Log4J 1.2 verwendet habe. Nachdem dies gesagt wurde, würde ich Ihre Fragen wie folgt beantworten:

  1. Programm auf SLF4J. Es hat eine schöne, einfache API, die alles bietet, was Sie wahrscheinlich von einem Protokollierungs-Framework benötigen. Wenn Sie aus irgendeinem Grund zu logback oder zu Log4J 1.2 oder zu einem anderen Zweck als Log4J 2.0 wechseln möchten, können Sie die Jars im Backend einfach austauschen.
  2. Definieren Sie die Gläser definitiv in den Anwendungskrieg. Sie sollten fast nie Jars im Verzeichnis lib des Anwendungsservers ablegen. Andernfalls wirken sie sich auf alle Webanwendungen auf diesem Anwendungsserver aus, nicht nur auf Ihre. Darüber hinaus können Jars im Verzeichnis lib des Anwendungsservers nicht durch die Bereitstellung von Webapps gesteuert werden, sondern müssen manuell verwaltet werden.
  3. Es sieht so aus, als würden Sie slf4j-api-1.7.2.jar , log4j-to-slf4j-2.0-beta4.jar , log4j-2.0-beta4.jar und log4j-core-2.0-beta4.jar sowie eventuelle Abhängigkeiten benötigen. Ich bin sicher, Maven wird die erforderlichen Abhängigkeiten einbringen, wenn Sie das verwenden.
1
Eric Galluzzo