Wyłącz rejestrowanie HttpClient

Używam commons-httpclient 3.1 w zestawie testów integracji. Domyślne rejestrowanie dla HttpClient jest bardzo głośne i nie mogę go wyłączyć. Próbowałem postępować zgodnie z instrukcjami tutaj, ale żadna z nich nie ma znaczenia.

Przeważnie muszę tylko zamknąć rejestrator org.apache.http.wire. Częścią problemu jest to, że nie wiem, jakiego typu rejestratora HttpClient próbuje użyć, a większość problemu polega na tym, że nigdy wcześniej nie korzystałem z tej biblioteki. Próbowałem utworzyć plik log4j.properties i wrzucić go do mojego folderu test / resources, zmodyfikować główny plik logging.properties w jre / lib i wysłać różne opcje rejestrowania do Mavena, jak określono na stronie logowania , i żadna z nich czynią różnicę.

Każda pomoc jest doceniana ... to doprowadza mnie do szału.

AKTUALIZACJA: Poprawka: wygląda na to, że dane wyjście faktycznie pochodzi z użycia HttpClient przez jwebunit, a nie mojego własnego. Tak czy inaczej, nie jest to pożądane.

UPDATE: Dzięki za dotychczasowe próby. Wypróbowałem wszystko, co sugerowano poniżej, ale nadal bez powodzenia. Mam plik commons-logging.properties w moim folderze src / test / resources z następującą zawartością

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

oraz plik log4j.properties w tym samym folderze o następującej zawartości

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

Jednak po uruchomieniu testów nadal otrzymuję takie wyniki:

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]"

To wyjście dla wszystkiego, co napotka przewód, sprawia, że ​​ta biblioteka jest dla mnie bezużyteczna ... do momentu, gdy będę mógł wymyślić, jak ją wyłączyć. Czy jest coś specjalnego, co muszę zrobić, aby odczytać tę konfigurację dziennika?

Zaktualizuj, log4j.propertiesaby uwzględnić:

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

Zauważ, że jeśli biblioteka Log4j nie jest zainstalowana, HttpClient (a tym samym JWebUnit) użyje logback. W tej sytuacji utwórz lub edytuj, logback.xmlaby uwzględnić:

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

Ustawienie poziomu logowania na WARNLog4j przy użyciu nazwy pakietu org.apache.commons.httpclientw log4j.properties nie będzie działać zgodnie z oczekiwaniami:

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

Dzieje się tak, ponieważ źródło HttpClient (v3.1) używa następujących nazw dzienników:

public static Wire HEADER_WIRE = new Wire(LogFactory.getLog("httpclient.wire.header"));
public static Wire CONTENT_WIRE = new Wire(LogFactory.getLog("httpclient.wire.content"));

Uwaga: niektóre z tych odpowiedzi mogą powtarzać rzeczy, które już wiesz (lub myślisz, że wiesz), ale jest trochę błędnych informacji krążących wokół tego pytania, więc zacznę od początku i wszystko przeliteruję

• Commons HttpClient używa Commons-Logging do wszystkich swoich potrzeb związanych z rejestrowaniem.
• Commons-Logging nie jest pełną platformą rejestrowania, ale raczej otoką kilku istniejących platform rejestrowania
• Oznacza to, że kiedy chcesz kontrolować dane wyjściowe logowania, konfigurujesz (głównie) bibliotekę inną niż Commons-Logging, ale ponieważ Commons-Logging obejmuje kilka innych bibliotek, trudno nam zgadnąć, którą skonfigurować, nie wiedząc Twoja dokładnie konfiguracja.
• Commons-Logging może logować się do log4j, ale może również logować się do java.util.logging (logowanie JDK1.4)
• Commons-Logging stara się być sprytny i zgadnąć, z którego systemu rejestrowania już korzystasz, i wysłać do niego swoje dzienniki.
• Jeśli nie masz jeszcze struktury rejestrowania i pracujesz na środowisku JRE w wersji 1.4 lub nowszej (którym naprawdę powinieneś być), prawdopodobnie będzie wysyłać swoje komunikaty dziennika do JDK logging ( java.util.logging)
• Poleganie na mechanizmie automatycznego wykrywania Commons-Logging jest podatne na błędy. Zwykłe dodanie log4j.jardo ścieżki klasy spowodowałoby, że zmieniłby mechanizm logowania, którego używa, co prawdopodobnie nie jest tym, czego chcesz
• Zaleca się, abyś wyraźnie powiedział Commons-Logging, której biblioteki logowania użyć
• Możesz to zrobić, tworząc commons-logging.propertiesplik zgodnie z tymi instrukcjami
• Kroki, które chcesz wykonać, aby skonfigurować rejestrowanie commons-httpclient, to
  1. Zdecyduj, której podstawowej struktury rejestrowania chcesz użyć. Istnieje wiele możliwości wyboru, ale prawdopodobnie log4jlubjava.util.logging są najlepsze opcje dla Ciebie.
  2. Skonfiguruj plik właściwości commons-logging tak, aby wskazywał poprawną Logimplementację. np. aby użyć log4j, umieść to w pliku właściwości: org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLoggerlub użyj zestawu logowania JDK org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger. Można je również ustawić jako właściwości systemu (np. Za pomocą -Dwiersza poleceń).
  3. Skonfiguruj podstawową implementację rejestrowania (np. Log4j), aby ignorować wiadomości, których nie chcesz, i wyświetlaj te, które chcesz.

To dużo kroków, ale to wszystko. Deweloperzy z Apache-commons zwykle zakładają, że masz już skonfigurowaną strukturę rejestrowania i mogą sprawdzić, która to jest, przez automatyczne wykrywanie.
Jeśli to nie jest prawdą w twoim przypadku, to zwykle wymaga trochę więcej pracy, aby wszystko działało.

Umieściłem to w moim pliku konfiguracyjnym log4j

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

Ogranicza to wyjście do poziomu ostrzegawczego lub wyższego

To zadziałało w moich testach;

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

W przypadku log4j dodaj następujący ciąg do log4j.properties(w katalogu aplikacji source):

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

W przypadku wylogowania następujące elementy wyeliminują logback.xmlhałas:

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

Dowiedzenie się tego zajęło zbyt dużo czasu, ale JWebUnit jest dostarczany w pakiecie z komponentem logowania Logback , więc nawet nie używa log4j.propertiesani commons-logging.properties.

Zamiast tego utwórz plik o nazwie logback.xmli umieść go w folderze kodu źródłowego (w moim przypadku 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>

Wydaje się, że logowanie zwrotne jest nadal w fazie rozwoju, a interfejs API nadal się zmienia, więc ten przykładowy kod może w przyszłości zakończyć się niepowodzeniem. Zobacz także to pytanie dotyczące StackOverflow .

Miałem ten problem podczas korzystania z RestAssured z JUnit. U mnie zadziałało to podejście programistyczne:

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

    //...
}

Używamy XML zamiast pliku właściwości, aby skonfigurować nasze dane wyjściowe logowania. Poniższy kod działał, aby uciszyć tę rozmowę.

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

Od dłuższego czasu nęka mnie ten sam problem i w końcu postanowiłem się temu przyjrzeć. Okazało się, że problem polega na tym, że mój projekt był zależny od http-builder-0.5.2.jar, który zawierał w sobie plik log4j.xml. I rzeczywiście, poziom dziennika dla org.apache.http.wire to DEBUG! Okazało się, że wystarczyło przejrzeć wszystkie pliki jar w moich zależnościach i wykonać polecenie „jar tvf” i grepowanie dla log4j.

Chociaż to odkrycie doprowadziło do ostatecznego rozwiązania polegającego na podniesieniu wersji mojej zależności http-builder do 0.6, nadal zastanawiam się, co musiało przejść przez umysł programisty podczas pakowania pliku log4j.xml do pliku jar. W każdym razie, to prawdopodobnie nie dotyczy tego wątku na razie. Pomyślałem jednak, że warto wspomnieć o tym rozwiązaniu, które znalazłem, biorąc pod uwagę, że kiedy szukałem rozwiązania wcześniej, moje nigdy się nie pojawiło. Mam nadzieję, że ktoś uzna to za przydatne.

W swoim log4.properties - czy masz taki zestaw jak ja poniżej i nie masz innych loggerów org.apache.httpw pliku?

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

Również jeśli org.apache.httpw pliku właściwości log4j nie określono żadnego poziomu logowania, wówczas poziom zostanie odziedziczony log4j.rootLogger. Więc jeśli log4j.rootLoggerustawiłeś, powiedzmy BŁĄD i wykupisz org.apache.httpustawienia w swoim log4j.properties, które powinny sprawić, że będzie on tylko rejestrowałERROR tylko wiadomości tylko przez dziedziczenie.

AKTUALIZACJA:

Utwórz commons-logging.propertiesplik i dodaj do niego następujący wiersz. Upewnij się również, że ten plik znajduje się w Twojej CLASSPATH.

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

Dodano ukończony plik log4j i kod do wywołania go dla OP. Ten plik log4j.properties powinien znajdować się w ścieżce CLASSPATH. W tej chwili zakładam stdout.

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

Oto kod, który musisz dodać do swojej klasy, aby wywołać rejestrator.

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
}

Prosty sposób Log4j i HttpCLient (w tym przypadku wersja 3.1, powinny działać na wyższych poziomach, mogą wymagać niewielkich zmian)

Upewnij się, że wszystkie zależności są poprawne, a pliki do pobrania MD5 !!!!

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

Miałem ten sam problem z JWebUnit. Zwróć uwagę, że jeśli używasz dystrybucji binarnej, Logback jest domyślnym programem rejestrującym. Aby użyć log4j z JWebUnit, wykonałem następujące kroki:

• usunięto Jary Logback
• dodaj bibliotekę mostu lod4j dla sfl4j - slf4j-log4j12-1.6.4.jar
• dodaj log4j.properties

Prawdopodobnie nie musisz usuwać słoików Logback, ale będziesz potrzebować dodatkowego kroku, aby zmusić slf4j do korzystania z log4j

Poniższe 2 linie całkowicie rozwiązały mój problem:

Logger.getLogger("org.apache.commons.httpclient").setLevel(Level.ERROR);
Logger.getLogger("httpclient").setLevel(Level.ERROR);

Dodaj poniższe wiersze do pliku właściwości log4j, a spowoduje to zamknięcie dzienników http: - log4j.logger.org.apache.http = OFF

Ja też miałem ten sam problem. Podczas [main] DEBUG org.apache.http.wiretestów cała konsola została zapełniona .

Rozwiązaniem, które działało dla mnie, było utworzenie logback-test.xml src / test / resources / logback-test.xml jak na https://github.com/bonigarcia/webdrivermanager-examples/blob/master/src/test/resources /logback-test.xml (ref - https://github.com/bonigarcia/webdrivermanager/issues/203 )

Aby wyświetlić informacje dotyczące logowania, zastąpiłem nazwę rejestratora = „io.github.bonigarcia” nazwą mojego pakietu

<?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>

to działa dla mnie z dodaniem "logback.xml" w ścieżce głównej klasy i poniżej ustawienia.

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

Do tego postu trafiłem, szukając rozwiązania podobnego problemu. Odpowiedź Tima była bardzo pomocna. podobnie jak Matt Baker, chcę po prostu wyłączyć dziennik httpClient bez zbytniej konfiguracji. Ponieważ nie byliśmy pewni, która implementacja rejestrowania pod common-logging została użyta, moim rozwiązaniem było wymuszenie użycia log4j poprzez wrzucenie pliku jar log4j w ścieżce klasy. Domyślne ustawienie konfiguracji log4j wyłącza wyjście debugowania common-httpclient. Oczywiście, aby uczynić go bardziej niezawodnym, możesz utworzyć pliki common-logging.properties i log4j.properties w celu dokładniejszego zdefiniowania konfiguracji rejestrowania.

Spróbuj umieścić

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

w twoim commons-logging.properties

W przypadku Apache 4.5.3, jeśli chcesz przenieść poziom logowania wszystkich klientów HTTP Apache do Warn , użyj:

log4j.logger.org.apache=WARN

Miałem ten sam problem podczas uruchamiania testów integracji jwebunit. Naprawiłem to, wyłączając logback i dodając slf4j-log4j12, na przykład:

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

Kiedyś to zajęło mi wieki, potrzebujesz tego:

log4j.logger.httpclient.wire=ERROR

Wydaje mi się, że HttpClient używa „httpclient.wire” jako nazwy programu rejestrującego, a nie „org.apache.commons.httpclient”.

Podstępne robale.

To zadziałało dla mnie.

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

Najlepszym rozwiązaniem, jakie znalazłem, było użycie wtyczki maven egzekwującej, aby całkowicie zapobiec używaniu wspólnego logowania. Następnie dodałem zamiast tego zależność slf4j do logowania. Więc dodaj poniższe do pliku pom.xml

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

a także dodaj wtyczkę maven-egzekutor

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

Wystąpił taki problem po ustawieniu HttpComponentsClientHttpRequestFactory dla mojego szablonu odpoczynku.

Ustawienie OkHttpClientHttpRequestFactory powinno rozwiązać problem z logowaniem do kosza.

Po prostu dodaj te dwie zależności w pliku pom: Próbowałem i udało mi się po wypróbowaniu wcześniejszej dyskusji.

<!--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 i domyślne informacje, gdy debugowanie nie będzie obecne; Możesz użyć:

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

zdefiniować informacje, które chcesz rejestrować: na przykład Wynik końcowy w ten sposób. Obecne będą tylko informacje, które chcę zarejestrować.

Próbowałem wszystkich powyższych rozwiązań bezskutecznie. Jedynym rozwiązaniem, które było dla mnie najbliższe, było sugerowanie utworzenia pliku logback.xml. To zadziałało, ale nic nie zostało zarejestrowane. Po zabawie z plikiem logback.xml skończyłem na tym

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

Teraz wszystkie poziomy poniżej DEBUG są poprawnie rejestrowane.

Z:

• Log2J 2 2.11.2
• HttpClient 4.5.7 (klient reszty elastsearch 7.0.0)
• Używanie pliku właściwości do konfigurowania

Można dodać:

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

Z „httpclient” w powyższym przykładzie jest wybraną nazwą logiczną.

(Testowane w aplikacji Java 11 OpenFX).

W moim przypadku używam konfiguracji XML i dołączam ją do pliku konfiguracyjnego

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

Spróbuj „log4j.logger.org.apache.http.headers = ERROR”

Dla mnie poniższe wiersze w log4j.propertiespliku posprzątały cały bałagan, który pojawił się podczas logowania HttpClient ... 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