Deaktivieren Sie die HttpClient-Protokollierung

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?

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"));

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.

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

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");

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>

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 .

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);

    //...
}

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>

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
}

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();

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.

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

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);

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

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>

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.

Versuchen Sie es

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

in Ihren commons-logging.properties

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

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>

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>

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.

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");

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>

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.

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.

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.

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.)

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>

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

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