Wyłącz rejestrowanie HttpClient

138

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?

Matt Baker
źródło
Dla wszystkich, którzy napotkali ten problem: pamiętaj, aby dodać -Dlog4j.debugdo opcji maszyny wirtualnej, aby upewnić się, że załadowany jest właściwy plik konfiguracyjny
Tommy,
3
Zobacz stackoverflow.com/questions/1436761/… . Fragment: public class Main { static { System.setProperty("org.apache.commons.logging.Log", "org.apache.commons.logging.impl.NoOpLog"); } // Rest of class as before }
PVS
1
Oficjalny dokument: hc.apache.org/httpclient-3.x/logging.html
Christophe Roussy
3
Czy to kiedykolwiek zostało rozwiązane dla OP. Dokładnie ten problem mnie zabija.
Collin Bell,
2
Czy to rozwiązane? Wypróbowałem wiele odpowiedzi, bez powodzenia.
Markvds,

Odpowiedzi:

87

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"));
Sud Monkey
źródło
21
W źródle 4.2.1 nazwy dzienników to: „org.apache.http.headers” i „org.apache.http.wire”, chociaż nawet przy ich używaniu hałaśliwe rejestrowanie Apache nie wydaje się wyłączać .
Tinclon
Dziękuję Ci!!! Ponadto: Jeśli masz ten problem gdzieś w swoim własnym kodzie, gdzie używasz httpclient i nie używasz jeszcze Log4j: pamiętaj również, aby dołączyć
plik
30

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.

Tim
źródło
1
To jest bardzo przydatna informacja; Naprawdę czuję, że powinien zostać dodany do tej strony . Napisałeś to tylko po to?
natem345
1
Człowieku, ta odpowiedź jest świetna, ale nie udało mi się. Używam Dropwizard i próbowałem wszystkiego, o czym wspomniałeś, bezskutecznie: '(
Vic Seedoubleyew
19

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

Philip Nuzhnyy
źródło
19

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");
Daniel Magnusson
źródło
19

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>
Ali Cheaito
źródło
1
Używam log4j. Dodanie pierwszych dwóch wierszy do dziennika całkowicie rozwiązuje mój problem. Wszystkie moje inne komunikaty dziennika są wyświetlane zgodnie z ustawionym poziomem. Podczas gdy dzienniki Apache nie. Wielka pomoc. Dzięki.
Arun Thundyill Saseendran,
Prawdopodobnie będzie się to różnić w zależności od sytuacji, ale aby wyłączyć strasznie szczegółowe rejestrowanie włączone po wyjęciu z pudełka z AWS SDK, jest to jedyne, które działało.
Matt Baker
To jest krótkie i słodkie i działa bez zarzutu.
Ajay Kumar
11

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 .

jevon
źródło
1
Jesteś piękna. Prawie zabiłem kota z tego powodu. Doprowadzało mnie to do szaleństwa.
Manish Patel
To było dla mnie rozwiązanie. Myślę, że to dlatego, że inne biblioteki, które włączyłem przejściowo, zawierały logowanie, więc zostało zablokowane na tym loggerze.
Nathan
11

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

    //...
}
tanacsg
źródło
3
Fantastycznie, jedyne rozwiązanie, które u mnie zadziałało. Dzięki wielkie.
lasote
Dziękuję Ci! Używałem dokładnie tego samego kodu na początku metody testowej, nic nie robiłem. Umieszczenie go we własnym @Beforelub @BeforeClassfunkcji działało pięknie.
ExactaBox
8

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>
barclay
źródło
5

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.

paulito415
źródło
Podobny problem podczas używania <!-- 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>. Usunięto zależność i dzienniki zniknęły. Dziękuję Ci!
adom
4

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
}
CoolBeans
źródło
Nie potrzebowałem pliku log4j.properties przed próbą użycia HttpClient. Próbowałem umieścić twoje linie w moim pliku src / test / resources / log4j.properties, ale to nie robi żadnej różnicy. Czy w ogóle umieszczanie opcji commons.logging w log4j.properties?
Matt Baker,
Tak, wspólne logowanie to tylko opakowanie wokół log4j. Jak wywołać rejestrator w klasie testowej?
CoolBeans
(Po twojej aktualizacji) Zrobiłem to tak, że powyższa linia była jedyną w moim pliku log4j.properties i nadal wszystko wypluwa.
Matt Baker,
1
Nie wywołuję rejestratora, HttpClient robi to samodzielnie.
Matt Baker,
Na podanym łączu jest napisane, że - „Uwaga: Log4j nie jest uwzględniony w dystrybucji HttpClient”. Więc zdecydowanie musisz dodać go do swojej CLASSPATH. Czy widzisz dane wyjściowe w stdout (konsola) lub w pliku dziennika? Utworzę przykładowy plik log4h z kodem, który wywoła go za Ciebie.
CoolBeans
4

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();
WiR3D
źródło
Powinienem umieścić to w mainmetodzie?
parsecer
@parsecer you can
WiR3D
3

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

Łukasz Lacki
źródło
Dzięki, miałem ten sam problem podczas korzystania z OpenRdf. Wszystkie inne wskazówki w tym wątku wydawały się nie działać, dopóki nie usunąłem słoików logback, teraz dziennik jest ładnie cichy.
amarillion
3

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);
Tosha
źródło
U mnie też to zadziałało, ale nie potrzebowałem: Logger.getLogger ("org.apache.commons.httpclient"). SetLevel (Level.ERROR);
Jamel Toms
3

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

Rancho
źródło
w testach jednostkowych (jeśli główny, wówczas główny) dodać @BeforeClass public static void BeforeClass() { PropertyConfigurator.configure("log4j.properties"); ...}plik log4j.properties z pojedynczej linii log4j.logger.org.apache.http = OFF powinny być w głównym (tuż powyżej src folderze)
Sasha Bond
3

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>
nantitv
źródło
3

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>
Lanzisun
źródło
2

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.

bcxw
źródło
2

Spróbuj umieścić

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

w twoim commons-logging.properties

Safrain
źródło
2

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
Adrian Elder
źródło
1

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>
David Pomeroy
źródło
1

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.

Adriaan Koster
źródło
1

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");
irlatech
źródło
0

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>
Big Daddy Software Man
źródło
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

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

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

sann05
źródło
0

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

Herman XU
źródło
0

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.

aggaton
źródło
0

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

Imifos
źródło
0

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

<logger name="org.apache.http">
    <level value="warn"/>
</logger>
Harun
źródło
0

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

Fracdroid
źródło
0

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
Dilip Muthukurussimana
źródło