Deaktivieren Sie die HttpClient-Protokollierung

133

Ich verwende commons-httpclient 3.1 in einer Integrationstestsuite. Die Standardprotokollierung für HttpClient ist extrem laut und ich kann sie anscheinend nicht deaktivieren. Ich habe versucht, den Anweisungen hier zu folgen , aber keine davon macht einen Unterschied.

Meistens muss ich nur den org.apache.http.wire-Logger zum Schweigen bringen. Ein Teil des Problems ist, dass ich nicht weiß, welche Art von Logger HttpClient zu verwenden versucht, und das meiste Problem ist, dass ich diese Bibliothek noch nie zuvor verwendet habe. Ich habe versucht, eine log4j.properties-Datei zu erstellen und in meinem Ordner test / resources abzulegen, die Master-Datei logging.properties in jre / lib zu ändern und die verschiedenen Protokollierungsoptionen wie auf der Protokollierungsseite angegeben an Maven zu senden , und keine davon einen Unterschied machen.

Jede Hilfe wird geschätzt ... das macht mich verrückt.

UPDATE: Eine Korrektur: Es scheint, dass die fragliche Ausgabe tatsächlich durch die Verwendung von HttpClient durch jwebunit stammt, nicht durch meine eigene. In jedem Fall ist es nicht wünschenswert.

UPDATE: Danke für die bisherigen Versuche. Ich habe alles versucht, was unten vorgeschlagen wurde, aber immer noch kein Glück. Ich habe eine Datei commons-logging.properties in meinem Ordner src / test / resources mit dem folgenden Inhalt

org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.Log4jFactory
log4j.configuration=log4j.properties

und eine Datei log4j.properties im selben Ordner mit dem folgenden Inhalt

log4j.rootLogger=ERROR, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p [%c] %m%n

#This is the line that should make httpclient shut up
log4j.logger.org.apache.http=ERROR

Wenn ich jedoch meine Tests durchführe, erhalte ich immer noch eine Reihe solcher Ausgaben:

21:57:41.413 [main] DEBUG org.apache.http.wire - << "                                   [\r][\n]"
21:57:41.413 [main] DEBUG org.apache.http.wire - << "[\r][\n]"
21:57:41.413 [main] DEBUG org.apache.http.wire - << "                                   [\r][\n]"
21:57:41.413 [main] DEBUG org.apache.http.wire - << "                               </ul>[\n]"
21:57:41.413 [main] DEBUG org.apache.http.wire - << "    [\n]"
21:57:41.424 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.425 [main] DEBUG org.apache.http.wire - << "[\r][\n]"
21:57:41.425 [main] DEBUG org.apache.http.wire - << "[\r][\n]"
21:57:41.425 [main] DEBUG org.apache.http.wire - << "                   </div>[\r][\n]"
21:57:41.425 [main] DEBUG org.apache.http.wire - << "                </li>[\r][\n]"
21:57:41.425 [main] DEBUG org.apache.http.wire - << "            [\r][\n]"
21:57:41.425 [main] DEBUG org.apache.http.wire - << "            [\r][\n]"
21:57:41.433 [main] DEBUG org.apache.http.wire - << "        </ul>[\n]"
21:57:41.433 [main] DEBUG org.apache.http.wire - << "</div>[\n]"
21:57:41.433 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.433 [main] DEBUG org.apache.http.wire - << "</div>[\n]"
21:57:41.433 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.433 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.433 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.433 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.433 [main] DEBUG org.apache.http.wire - << "<div class="details">[\n]"
21:57:41.442 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.443 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.443 [main] DEBUG org.apache.http.wire - << "<div class="details-body details-precis  ">[\n]
"
21:57:41.443 [main] DEBUG org.apache.http.wire - << "<div class="details-state">[\n]"
21:57:41.443 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.443 [main] DEBUG org.apache.http.wire - << "</div>[\n]"
21:57:41.443 [main] DEBUG org.apache.http.wire - << "</div>[\n]"
21:57:41.443 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.455 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.455 [main] DEBUG org.apache.http.wire - << "</div>[\n]"
21:57:41.455 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.455 [main] DEBUG org.apache.http.wire - << "</div>[\n]"
21:57:41.455 [main] DEBUG org.apache.http.wire - << "</div>[\n]"
21:57:41.455 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.455 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.455 [main] DEBUG org.apache.http.wire - << "[\n]"
21:57:41.455 [main] DEBUG org.apache.http.wire - << "[\r][\n]"
Destroying 1 processes21:57:41.465 [main] DEBUG org.apache.http.wire - << "[\r][\n]"

Diese Ausgabe für alles, was über den Draht kommt, macht diese Bibliothek für mich unbrauchbar ... bis ich herausfinden kann, wie ich sie ausschalten kann. Muss ich etwas Besonderes tun, damit diese Protokollkonfiguration eingelesen wird?

Matt Baker
quelle
Für alle, die auf dieses Problem stoßen: Stellen Sie sicher, dass Sie -Dlog4j.debugIhre VM-Optionen erweitern, um sicherzustellen, dass die richtige Konfigurationsdatei geladen wird
Tommy
3
Siehe stackoverflow.com/questions/1436761/… . Zum Auszug: public class Main { static { System.setProperty("org.apache.commons.logging.Log", "org.apache.commons.logging.impl.NoOpLog"); } // Rest of class as before }
PVS
1
Offizielles Dokument: hc.apache.org/httpclient-3.x/logging.html
Christophe Roussy
3
Wurde dies jemals für OP gelöst? Dieses genaue Problem bringt mich um.
Collin Bell
2
Ist das gelöst? Versuchte alle Antworten, kein Glück.
Markvds

Antworten:

85

Update log4j.propertiesmit:

log4j.logger.httpclient.wire.header=WARN
log4j.logger.httpclient.wire.content=WARN

Beachten Sie, dass HttpClient (und damit JWebUnit) Logback verwendet, wenn die Log4j-Bibliothek nicht installiert ist. Erstellen oder bearbeiten Sie logback.xmlin dieser Situation Folgendes :

<configuration>
    <logger name="org.apache" level="WARN" />
    <logger name="httpclient" level="WARN" /> 
</configuration>

Das Festlegen der Protokollebene WARNmit Log4j unter Verwendung des Paketnamens org.apache.commons.httpclientin log4j.properties funktioniert nicht wie erwartet:

log4j.logger.org.apache.commons.httpclient=WARN

Dies liegt daran, dass die Quelle für HttpClient (v3.1) die folgenden Protokollnamen verwendet:

public static Wire HEADER_WIRE = new Wire(LogFactory.getLog("httpclient.wire.header"));
public static Wire CONTENT_WIRE = new Wire(LogFactory.getLog("httpclient.wire.content"));
Sud Affe
quelle
19
In der 4.2.1-Quelle lauten die Protokollnamen: "org.apache.http.headers" und "org.apache.http.wire", obwohl selbst wenn ich sie verwende, die verrauschte Apache-Protokollierung für mich nicht abgeschaltet zu werden scheint .
Tinclon
Danke dir!!! Außerdem: Wenn Sie dieses Problem irgendwo in Ihrem eigenen Code haben, wo Sie httpclient verwenden und Log4j noch nicht verwenden: Denken Sie auch daran, das log4j-JAR in den Klassenpfad aufzunehmen ...
FelixD
30

Hinweis: Einige dieser Antworten wiederholen möglicherweise Dinge, die Sie bereits kennen (oder zu wissen glauben), aber es gibt ein paar Fehlinformationen zu dieser Frage, daher werde ich am Anfang beginnen und alles darlegen

  • Commons HttpClient verwendet Commons-Logging für alle Protokollierungsanforderungen.
  • Commons-Logging ist kein vollständiges Protokollierungsframework, sondern ein Wrapper um mehrere vorhandene Protokollierungsframeworks
  • Das bedeutet , dass , wenn Sie die Protokollausgabe steuern möchten, können Sie (meistens) eine Bibliothek andere als Commons-Logging Konfiguration am Ende, sondern weil Commons-Logging um mehrere andere Bibliotheken wickelt, ist es schwer für uns , was man zu konfigurieren , zu erraten , ohne zu wissen Ihr genaues Setup.
  • Commons-Logging kann sich bei log4j anmelden, aber auch bei java.util.logging(JDK1.4-Protokollierung).
  • Commons-Logging versucht, klug zu sein und zu erraten, welches Protokollierungsframework Sie bereits verwenden, und seine Protokolle an dieses zu senden.
  • Wenn Sie noch kein Protokollierungsframework haben und auf einer JRE ausgeführt werden, die 1.4 oder höher ist (was Sie wirklich sein sollten), sendet es wahrscheinlich seine Protokollnachrichten an die JDK-Protokollierung ( java.util.logging).
  • Das Verlassen auf den automatischen Erkennungsmechanismus von Commons-Logging ist fehleranfällig. Durch einfaches Hinzufügen log4j.jarzum Klassenpfad wird geändert, welcher Protokollierungsmechanismus verwendet wird, was wahrscheinlich nicht das ist, was Sie möchten
  • Es ist vorzuziehen, dass Sie Commons-Logging explizit mitteilen, welche Protokollierungsbibliothek verwendet werden soll
  • Sie können dies tun, indem Sie eine commons-logging.propertiesDatei gemäß diesen Anweisungen erstellen
  • Die Schritte, die Sie zum Konfigurieren der Commons-httpclient-Protokollierung ausführen möchten, sind:
    1. Entscheiden Sie, welches zugrunde liegende Protokollierungsframework Sie verwenden möchten. Es gibt eine Reihe von Möglichkeiten, aber wahrscheinlich log4joder java.util.loggingsind die besten Optionen für Sie.
    2. Richten Sie die Commons-Logging-Eigenschaftendatei so ein, dass sie auf die richtige LogImplementierung verweist. Um beispielsweise log4j zu verwenden, fügen Sie dies in die Eigenschaftendatei ein: org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLoggeroder verwenden Sie den JDK-Protokollierungssatz org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger. Diese können auch als Systemeigenschaften festgelegt werden (z. B. -Düber die Befehlszeile).
    3. Konfigurieren Sie die zugrunde liegende Protokollierungsimplementierung (z. B. log4j) so, dass die nicht gewünschten Nachrichten ignoriert und die gewünschten Nachrichten ausgegeben werden.

Das sind viele Schritte, aber das ist es, was es braucht. Die Entwickler von Apache-commons gehen in der Regel davon aus, dass Sie bereits ein Protokollierungsframework konfiguriert haben, und können durch automatische Erkennung herausfinden, um welches Framework es sich handelt.
Wenn das für Sie nicht zutrifft, ist es in der Regel etwas mehr Arbeit, um die Dinge zum Laufen zu bringen.

Tim
quelle
1
Dies sind sehr nützliche Informationen. Ich habe wirklich das Gefühl, dass es dieser Seite hinzugefügt werden sollte . Hast du es nur dafür geschrieben?
Natem345
1
Mann, diese Antwort ist großartig, aber ich habe es nicht geschafft, dass es funktioniert. Ich benutze Dropwizard und habe alles versucht, was Sie erwähnt haben, ohne Erfolg: '(
Vic Seedoubleyew
19

Ich habe dies in meine log4j-Konfigurationsdatei eingefügt

log4j.logger.org.apache.http.wire=WARN

Dies begrenzt die Ausgabe auf Warnstufe oder höher

Philip Nuzhnyy
quelle
19

Dies funktionierte für meine Tests;

java.util.logging.Logger.getLogger("org.apache.http.wire").setLevel(java.util.logging.Level.FINEST);
java.util.logging.Logger.getLogger("org.apache.http.headers").setLevel(java.util.logging.Level.FINEST);
System.setProperty("org.apache.commons.logging.Log", "org.apache.commons.logging.impl.SimpleLog");
System.setProperty("org.apache.commons.logging.simplelog.showdatetime", "true");
System.setProperty("org.apache.commons.logging.simplelog.log.httpclient.wire", "ERROR");
System.setProperty("org.apache.commons.logging.simplelog.log.org.apache.http", "ERROR");
System.setProperty("org.apache.commons.logging.simplelog.log.org.apache.http.headers", "ERROR");
Daniel Magnusson
quelle
18

Fügen Sie für log4j Folgendes hinzu log4j.properties(im sourceVerzeichnis der Anwendung ):

log4j.logger.org.apache=WARN
log4j.logger.httpclient=WARN

Bei der Rückmeldung logback.xmlwird das Rauschen durch Folgendes gelöscht :

<configuration>
    <logger name="org.apache" level="WARN" />
    <logger name="httpclient" level="WARN" /> 
</configuration>
Ali Cheaito
quelle
1
Ich benutze log4j. Das Hinzufügen der ersten beiden Zeilen im Protokolllöser ist mein Problem vollständig. Alle meine anderen Protokollmeldungen werden entsprechend der von mir festgelegten Stufe angezeigt. Während Apache-Protokolle dies nicht tun. Tolle Hilfe. Vielen Dank.
Arun Thundyill Saseendran
Dies hängt wahrscheinlich von Ihrer Situation ab. Wenn Sie jedoch die schrecklich ausführliche Protokollierung deaktivieren, die mit dem AWS SDK sofort aktiviert wurde, ist dies die einzige, die funktioniert hat.
Matt Baker
11

Es hat viel zu lange gedauert, um dies herauszufinden, aber JWebUnit wird mit der Logback- Protokollierungskomponente geliefert , sodass es nicht einmal log4j.propertiesoder verwendet commons-logging.properties.

Erstellen Sie stattdessen eine Datei mit dem Namen logback.xmlund legen Sie sie in Ihrem Quellcode-Ordner ab (in meinem Fall src):

<configuration debug="false">
  <!-- definition of appender STDOUT -->
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
      <pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
    </encoder>
  </appender>

  <root level="ERROR">
    <!-- appender referenced after it is defined -->
    <appender-ref ref="STDOUT"/>
  </root> 
</configuration>

Logback scheint sich noch in der Entwicklung zu befinden und die API scheint sich noch zu ändern, sodass dieses Codebeispiel möglicherweise in Zukunft fehlschlägt. Siehe auch diese StackOverflow-Frage .

jevon
quelle
1
Du schöne. Ich hätte wegen dieser Sache fast eine Katze getötet. Es machte mich wahnsinnig.
Manish Patel
Das war die Lösung für mich. Ich denke, das liegt daran, dass andere Bibliotheken, die ich transitiv aufgenommen habe, Logback enthalten haben, sodass es für diesen Logger gesperrt wurde.
Nathan
10

Ich hatte dieses Problem bei der Verwendung von RestAssured mit JUnit. Für mich hat dieser programmatische Ansatz funktioniert:

@BeforeClass
public static void setUpClass() {
    ch.qos.logback.classic.Logger root = (ch.qos.logback.classic.Logger) org.slf4j.LoggerFactory.getLogger("org.apache.http");
    root.setLevel(ch.qos.logback.classic.Level.INFO);

    //...
}
tanacsg
quelle
2
Fantastisch, die einzige Lösung, die es für mich funktioniert hat. Vielen Dank.
Lasote
Danke dir! Hat zu Beginn der Testmethode genau den gleichen Code verwendet, hat nichts getan. Das Platzieren in einer eigenen @Beforeoder @BeforeClassFunktion hat wunderbar funktioniert.
ExactaBox
8

Wir verwenden XML anstelle einer Eigenschaftendatei, um unsere Protokollausgabe zu konfigurieren. Der folgende Code hat dieses Geschwätz zum Schweigen gebracht.

<logger name="org.apache.commons.httpclient">
    <level value="fatal"/>
</logger>

<logger name="httpclient.wire.header">
    <level value="fatal"/>
</logger>

<logger name="httpclient.wire.content">
    <level value="fatal"/>
</logger>
Barclay
quelle
4

In Ihren log4.properties - haben Sie dieses Set wie unten und keine anderen org.apache.httpLogger in der Datei?

-org.apache.commons.logging.simplelog.log.org.apache.http=ERROR

Auch wenn org.apache.httpin Ihrer log4j-Eigenschaftendatei keine Protokollebene angegeben ist, erbt diese die log4j.rootLoggerEbene. Wenn Sie log4j.rootLoggeralso ERROR festgelegt haben und org.apache.httpEinstellungen in Ihren log4j.properties vornehmen, sollten ERRORNachrichten nur durch Vererbung protokolliert werden.

AKTUALISIEREN:

Erstellen Sie eine commons-logging.propertiesDatei und fügen Sie die folgende Zeile hinzu. Stellen Sie außerdem sicher, dass sich diese Datei in Ihrem CLASSPATH befindet.

org.apache.commons.logging.LogFactory = org.apache.commons.logging.impl.Log4jFactory

Es wurde eine fertige log4j-Datei und der Code zum Aufrufen für das OP hinzugefügt. Diese log4j.properties sollten sich in Ihrem CLASSPATH befinden. Ich gehe für den Moment von Standard aus.

log4j.configuration=log4j.properties 
log4j.rootLogger=ERROR, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%5p [%c] %m%n

log4j.logger.org.apache.http=ERROR

Hier ist ein Code, den Sie Ihrer Klasse hinzufügen müssen, um den Logger aufzurufen.

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory; 

public class MyClazz
{
    private Log log = LogFactory.getLog(MyClazz.class);
    //your code for the class
}
Kühle Bohnen
quelle
Ich brauchte keine log4j.properties-Datei, bevor ich versuchte, HttpClient zu verwenden. Ich habe versucht, Ihre Zeilen in meine Datei src / test / resources / log4j.properties aufzunehmen, aber es hat keinen Unterschied gemacht. Ist es überhaupt richtig, commons.logging-Optionen in log4j.properties einzufügen?
Matt Baker
Ja, Commons-Logging ist nur ein Wrapper um log4j. Wie rufen Sie den Logger in Ihrer Testklasse auf?
CoolBeans
(Nach Ihrem Update) Ich habe es so gemacht, dass die obige Zeile die einzige in meiner log4j.properties-Datei war und immer noch alles ausspuckt.
Matt Baker
1
Ich rufe den Logger nicht auf, HttpClient macht es alleine.
Matt Baker
Auf dem von Ihnen angegebenen Link steht: "Hinweis: Log4j ist nicht in der HttpClient-Distribution enthalten." Sie müssen es also unbedingt zu Ihrem KLASSENPFAD hinzufügen. Sehen Sie die Ausgabe in stdout (Konsole) oder in einer Protokolldatei? Ich werde eine log4h-Beispieldatei mit Code erstellen, um sie für Sie aufzurufen.
CoolBeans
4

Einfacher Weg Log4j und HttpCLient (v3.1 in diesem Fall, sollte für höhere arbeiten, könnte geringfügige Änderungen erfordern)

Stellen Sie sicher, dass alle Abhängigkeiten korrekt sind und MD5 Ihre Downloads !!!!

import org.apache.commons.httpclient.HttpClient;  
import org.apache.log4j.Level;  
import org.apache.log4j.Logger;  

---

Logger.getLogger("org.apache.commons.httpclient").setLevel(Level.WARN);
Logger.getLogger("httpclient.wire.header").setLevel(Level.WARN);
Logger.getLogger("httpclient.wire.content").setLevel(Level.WARN);

HttpClient client = new HttpClient();
WiR3D
quelle
Soll ich es in mainMethode setzen?
Parsecer
@ Parsecer können Sie
WiR3D
4

Ich bin schon seit einiger Zeit von demselben Problem geplagt und habe mich schließlich entschlossen, dies zu untersuchen. Es stellte sich heraus, dass mein Projekt eine Abhängigkeit von http-builder-0.5.2.jar hatte, die eine log4j.xml-Datei in sich selbst bündelte. Und sicher war die Protokollstufe für org.apache.http.wire DEBUG! Die Art und Weise, wie ich es fand, war nur, alle JAR-Dateien in meinen Abhängigkeiten durchzugehen und "JAR-TVF" zu machen und nach log4j zu suchen.

Diese Entdeckung führte zwar zu der möglichen Lösung, die Version meiner http-Builder-Abhängigkeit auf 0,6 zu erhöhen, aber es verwirrt mich immer noch, was dem Entwickler beim Bündeln der Datei log4j.xml in die JAR-Datei durch den Kopf gegangen sein muss. Jedenfalls ist das für diesen Thread momentan wahrscheinlich nicht relevant. Aber ich dachte, es ist nützlich, diese Lösung zu erwähnen, die ich gefunden habe, da meine bei der Suche nach einer Lösung noch nie aufgetaucht ist. Hoffentlich findet das jemand nützlich.

paulito415
quelle
Ähnliches Problem bei der Verwendung <!-- https://mvnrepository.com/artifact/com.fredericboisguerin.excel/excel-reader-writer --> <dependency> <groupId>com.fredericboisguerin.excel</groupId> <artifactId>excel-reader-writer</artifactId> <version>2.1</version> </dependency>. Die Abhängigkeit wurde entfernt und die Protokolle wurden entfernt. Danke dir!
Adom
3

Ich hatte das gleiche Problem mit JWebUnit. Bitte beachten Sie, dass bei Verwendung der Binärverteilung Logback ein Standardlogger ist. Um log4j mit JWebUnit zu verwenden, habe ich folgende Schritte ausgeführt:

  • Logback-Gläser entfernt
  • Fügen Sie die lod4j-Brückenbibliothek für sfl4j - slf4j-log4j12-1.6.4.jar hinzu
  • füge log4j.properties hinzu

Wahrscheinlich müssen Sie keine Logback-Jars entfernen, aber Sie benötigen einen zusätzlichen Schritt, um slf4j zur Verwendung von log4j zu zwingen

Lukasz Lacki
quelle
Danke, ich hatte das gleiche Problem bei der Verwendung von OpenRdf. Alle anderen Tipps in diesem Thread schienen keine Wirkung zu haben, bis ich die Logback-Gläser entfernte. Jetzt ist das Log schön leise.
Amarillion
3

Die folgenden 2 Zeilen haben mein Problem vollständig gelöst:

Logger.getLogger("org.apache.commons.httpclient").setLevel(Level.ERROR);
Logger.getLogger("httpclient").setLevel(Level.ERROR);
Tosha
quelle
Dies funktionierte auch für mich, aber ich brauchte nicht: Logger.getLogger ("org.apache.commons.httpclient"). SetLevel (Level.ERROR);
Jamel Toms
3

Fügen Sie die folgenden Zeilen in die Eigenschaftendatei log4j ein, um die http-Protokolle zu schließen: - log4j.logger.org.apache.http = OFF

Rancho
quelle
@BeforeClass public static void BeforeClass() { PropertyConfigurator.configure("log4j.properties"); ...}Fügen Sie in Unit-Tests (wenn main, dann in main) auch die Datei log4j.properties mit der einzelnen Zeile hinzu. log4j.logger.org.apache.http = OFF sollte sich im Stammverzeichnis (direkt über dem Ordner src) befinden
Sasha Bond
3

Ich hatte auch das gleiche Problem. Die gesamte Konsole wurde [main] DEBUG org.apache.http.wirewährend der Ausführung der Tests gefüllt .

Die Lösung, die für mich funktioniert hat, war das Erstellen einer logback-test.xml src / test / resources / logback-test.xml wie unter https://github.com/bonigarcia/webdrivermanager-examples/blob/master/src/test/resources /logback-test.xml (ref - https://github.com/bonigarcia/webdrivermanager/issues/203 )

Um meine Protokollinformationen anzuzeigen, habe ich logger name = "io.github.bonigarcia" durch meinen Paketnamen ersetzt

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n</pattern>
        </encoder>
    </appender>

    <logger name="com.mypackage" level="DEBUG" />
    <logger name="org" level="INFO" />
    <logger name="com" level="INFO" />

    <root level="INFO">
        <appender-ref ref="STDOUT" />
    </root>

</configuration>
nantitv
quelle
2

Ich wurde zu diesem Beitrag geführt, als ich nach einer Lösung für ein ähnliches Problem suchte. Tims Antwort war sehr hilfreich. Wie Matt Baker möchte ich nur das httpClient-Protokoll ohne zu viel Konfiguration schließen. Da wir nicht sicher waren, welche Protokollierungsimplementierung unter der allgemeinen Protokollierung verwendet wurde, bestand meine Lösung darin, die Verwendung von log4j zu erzwingen, indem die JAR-Datei log4j in den Klassenpfad geworfen wurde. Die Standardeinstellung der log4j-Konfiguration schaltet die Common-httpclient-Debug-Ausgabe aus. Um die Robustheit zu erhöhen, können Sie natürlich die Dateien common-logging.properties und log4j.properties erstellen, um Ihre Protokollierungskonfigurationen weiter zu definieren.

bcxw
quelle
2

Versuchen Sie es

org.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog

in Ihren commons-logging.properties

Safrain
quelle
2

Verwenden Sie für Apache 4.5.3 Folgendes, wenn Sie die Ebene für alle Apache-HTTP-Client-Protokollierungen auf Warnen verschieben möchten :

log4j.logger.org.apache=WARN
Adrian Elder
quelle
2

Es funktioniert für mich mit dem Hinzufügen von "logback.xml" im Klassenstammpfad und unter der Einstellung.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <logger name="org.apache" level="WARN"/>
    <logger name="httpclient" level="WARN"/>
</configuration>
Lanzisun
quelle
1

Ich hatte das gleiche Problem beim Ausführen von Jwebunit-Integrationstests. Ich habe es behoben, indem ich logback ausgeschlossen und slf4j-log4j12 hinzugefügt habe, wie folgt:

<dependency>
  <groupId>net.sourceforge.jwebunit</groupId>
  <artifactId>jwebunit-htmlunit-plugin</artifactId>
  <version>3.0</version>
  <exclusions>
    <exclusion>
      <groupId>ch.qos.logback</groupId>
      <artifactId>logback-classic</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>org.slf4j</groupId>
  <artifactId>slf4j-log4j12</artifactId>
</dependency>
David Pomeroy
quelle
1

Ich habe ewig gebraucht, um es einmal herauszufinden. Du brauchst Folgendes:

log4j.logger.httpclient.wire=ERROR

Ich denke, HttpClient verwendet "httpclient.wire" als Loggernamen, nicht "org.apache.commons.httpclient".

Hinterhältige Kerle.

Adriaan Koster
quelle
1

Das hat bei mir funktioniert.

System.setProperty("org.apache.commons.logging.Log", "org.apache.commons.logging.impl.SimpleLog");
System.setProperty("org.apache.commons.logging.simplelog.showdatetime", "true");
System.setProperty("org.apache.commons.logging.simplelog.log.httpclient.wire.header", "error");
System.setProperty("org.apache.commons.logging.simplelog.log.org.apache.http", "error");
System.setProperty("log4j.logger.org.apache.http", "error");
System.setProperty("log4j.logger.org.apache.http.wire", "error");
System.setProperty("org.apache.commons.logging.simplelog.log.org.apache.commons.httpclient", "error");
irlatech
quelle
0

Die beste Lösung, die ich gefunden habe, war die Verwendung des Maven Enforcer-Plugins, um zu verhindern, dass Commons-Logging insgesamt verwendet wird. Dann habe ich stattdessen die slf4j-Abhängigkeit für die Protokollierung hinzugefügt. Fügen Sie also Folgendes zu Ihrer pom.xml hinzu

<dependency>
        <groupId>org.slf4j</groupId>
        <artifactId>slf4j-api</artifactId>
        <version>[your version here]</version>
    </dependency>

und fügen Sie auch das Maven-Enforcer-Plugin hinzu

<plugin>
           <groupId>org.apache.maven.plugins</groupId>
           <artifactId>maven-enforcer-plugin</artifactId>
           <version>[your version here]</version>
           <executions>
               <execution>
                   <id>enforce</id>
                   <configuration>
                       <rules>
                           <DependencyConvergence />
                           <bannedDependencies>
                               <excludes>
                                   <exclude>commons-logging:commons-logging</exclude>
                               </excludes>
                           </bannedDependencies>
                       </rules>
                   </configuration>
                   <goals>
                       <goal>enforce</goal>
                   </goals>
               </execution>
           </executions>
       </plugin>
Big Daddy Software Man
quelle
Failed to execute goal org.apache.maven.plugins:maven-enforcer-plugin:3.0.0-M2:enforce (enforce) on project gs-serving-web-content: Some Enforcer rules have failed. Look above for specific messages explaining why the rule failed
Parsecer
0

Ich habe ein solches Problem festgestellt, nachdem ich HttpComponentsClientHttpRequestFactory für meine Restvorlage festgelegt habe.

Durch Festlegen von OkHttpClientHttpRequestFactory sollte das Problem mit der Papierkorbprotokollierung behoben werden.

sann05
quelle
0

Fügen Sie einfach diese beiden Abhängigkeiten in die POM-Datei ein: Ich habe versucht, erfolgreich zu sein, nachdem ich die Diskussion zuvor versucht habe.

<!--Using logback-->
<dependency>
   <groupId>commons-logging</groupId>
   <artifactId>commons-logging</artifactId>
   <version>1.2</version>
</dependency>
<dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-starter-logging</artifactId>
</dependency>

Commons-Logging -> Logback und Standardinfo, während Debug nicht vorhanden ist; Sie können verwenden:

private static Logger log = LoggerFactory.getLogger(HuaweiAPI.class);

So definieren Sie die Informationen, die Sie protokollieren möchten: Gefällt mir das Endergebnis wie folgt. Es sind nur die Informationen vorhanden, die ich protokollieren möchte.

Herman XU
quelle
0

Ich habe alle oben genannten Lösungen ohne Erfolg ausprobiert. Die einzige Lösung, die mir am nächsten kam, war die, die vorschlug, eine logback.xml zu erstellen. Das hat funktioniert, aber es wurde nichts protokolliert. Nachdem ich mit der logback.xml herumgespielt hatte, kam ich zu diesem Ergebnis

<configuration>
  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <withJansi>true</withJansi>
    <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
    </encoder>
  </appender>
  <root level="INFO">
    <appender-ref ref="STDOUT"/>
  </root>
</configuration>

Jetzt werden alle Ebenen unter DEBUG korrekt protokolliert.

Aggaton
quelle
0

Mit:

  • Log2J 2 2.11.2
  • HttpClient 4.5.7 (Elasticsearch 7.0.0 Rest Client)
  • Verwenden der Eigenschaftendatei zum Konfigurieren

Man kann hinzufügen:

logger.httpclient.name=org.apache.http
logger.httpclient.level=info

Wenn 'httpclient' im obigen Beispiel ein logischer Name ist, den Sie wählen.

(Getestet mit Java 11 OpenFX.)

Imifos
quelle
0

In meinem Fall verwende ich die XML-Konfiguration und hänge diese an die Konfigurationsdatei an

<logger name="org.apache.http">
    <level value="warn"/>
</logger>
Harun
quelle
0

Versuchen Sie 'log4j.logger.org.apache.http.headers = ERROR'

Fracdroid
quelle
0

Für mich haben die folgenden Zeilen in der log4j-Prop-Datei all das Durcheinander beseitigt, das durch die HttpClient-Protokollierung entstanden ist ... Hurra !!! :) :)

log4j.logger.org.apache.http.headers=ERROR
log4j.logger.org.apache.http.wire=ERROR
log4j.logger.org.apache.http.impl.conn.PoolingHttpClientConnectionManager=ERROR
log4j.logger.org.apache.http.impl.conn.DefaultManagedHttpClientConnection=ERROR
log4j.logger.org.apache.http.conn.ssl.SSLConnectionSocketFactory=ERROR
log4j.logger.org.springframework.web.client.RestTemplate=ERROR
log4j.logger.org.apache.http.client.protocol.RequestAddCookies=ERROR
log4j.logger.org.apache.http.client.protocol.RequestAuthCache=ERROR
log4j.logger.org.apache.http.impl.execchain.MainClientExec=ERROR
log4j.logger.org.apache.http.impl.conn.DefaultHttpClientConnectionOperator=ERROR
Dilip Muthukurussimana
quelle