Désactiver la journalisation HttpClient

Remarque: une partie de cette réponse pourrait répéter des choses que vous savez déjà (ou pense savoir), mais il est un peu de la mauvaise information qui circulent sur cette question, je vais donc commencer par le début et sort tout

• Communes HttpClient utilise Commons-Logging pour l'ensemble de son enregistrement.
• Commons-Logging n'est pas un plein de journalisation, mais plutôt, est un wrapper autour de plusieurs journalisation des cadres
• Qui signifie que lorsque vous souhaitez contrôler la sortie d'enregistrement, vous (surtout) la fin de la configuration d'une bibliothèque autre que Commons-Logging, mais parce que Commons-Logging s'enroule autour de plusieurs autres bibliothèques, il est difficile pour nous de deviner lequel de configurer sans savoir exactement votre installation.
• Commons-Logging peut se connecter à log4j, mais il peut également se connecter à java.util.logging (JDK1.4 enregistrement)
• Commons-Logging essaie d'être intelligent et devinez qui journalisation vous utilisez déjà, et d'envoyer ses journaux pour que.
• Si vous n'avez pas de journalisation, et sont en cours d'exécution sur un JRE 1,4 ou au-dessus (que vous devriez vraiment être) ensuite, il sera probablement de l'envoi de messages du journal pour le JDK d'enregistrement (java.util.logging)
• En s'appuyant sur Commons-Logging de la détection automatique du mécanisme est sujette à l'erreur. Simplement en ajoutant log4j.jar sur le classpath serait la cause de sélectionner le mécanisme de journalisation il utilise, ce qui n'est probablement pas ce que vous voulez
• Il est préférable pour vous indiquer explicitement Commons-Logging de journalisation de la bibliothèque à utiliser
• Vous pouvez le faire en créant un commons-logging.properties fichier comme par ces instructions
• Les étapes à suivre pour configurer le commons-httpclient de journalisation sont
  1. Décider qui sous-tendent la journalisation cadre que vous souhaitez utiliser. Il y a un certain nombre de choix, mais probablement log4j ou java.util.logging sont les meilleures options pour vous.
  2. Set-up de la chambre des communes d'enregistrement de fichier de propriétés pour pointer vers le bon Log mise en œuvre. par exemple, pour utiliser log4j, mettre ceci dans le fichier de propriétés: org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger, ou d'utiliser le JDK de journalisation ensemble org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger. Ceux-ci peuvent également être définies comme des propriétés du système (par exemple, à l'aide de -D sur la ligne de commande).
  3. Configurer le sous-jacent de la journalisation de la mise en œuvre (par exemple, log4j) pour ignorer les messages que vous ne voulez pas, de sortie et les messages que vous voulez.

Qui a beaucoup d'étapes, mais c'est ce qu'il faut. Les développeurs de Apache commons ont tendance à supposer que vous aurez déjà une journalisation configuré, et ils peuvent travailler en auto-découverte.

Si ce n'est pas vrai pour vous, alors il a tendance à être un peu plus de travail pour obtenir des choses en cours d'exécution.

Cela a fonctionné pour mes 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");

Il a fallu beaucoup trop de temps à la trouver, mais JWebUnit est livré avec le Logback journalisation composant, afin de ne même pas utiliser log4j.properties ou commons-logging.properties.

Au lieu de cela, créez un fichier appelé logback.xml et le placer dans le code source de votre dossier (dans mon cas, 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 semble être encore en cours de développement et l'API semble encore être en train de changer, de sorte que cet exemple de code peut échouer dans l'avenir. Voir aussi cette question StackOverflow.

J'ai eu ce problème pendant l'utilisation de RestAssured avec JUnit. Pour moi, cette approche programmatique travaillé:

@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);
//...
}

Façon Simple Log4j et HttpCLient (v3.1 dans ce cas, doivent travailler de plus, pourrait nécessiter des modifications mineures)

Assurez-vous que toutes les dépendances sont corrects, et le MD5 de vos téléchargements!!!!

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

J'ai eu le même problème avec JWebUnit. Veuillez noter que si vous utilisez la distribution binaire puis Logback est un défaut de l'enregistreur de. Pour utiliser log4j avec JWebUnit j'ai effectué les étapes suivantes:

• retiré Logback pots
• ajouter lod4j pont de la bibliothèque pour sfl4j - slf4j-log4j12-1.6.4.jar
• ajouter log4j.propriétés

Probablement vous n'avez pas à supprimer Logback pots mais vous aurez besoin d'une étape supplémentaire de la force de slf4j à utiliser log4j

J'ai été amené à ce poste lors de la recherche de solution pour un problème similaire. Tim réponse a été très utile. comme Matt Baker, je veux juste arrêter httpClient journal sans trop de configuration. Comme nous n'étions pas sûrs de journalisation à la mise en œuvre sous commun d'enregistrement a été utilisé, Ma solution a été de force à l'aide de log4j par des jets de log4j fichier jar dans le chemin de classe. Le réglage par défaut de configuration log4j s'arrête commun-httpclient la sortie de débogage. Bien sûr, pour le rendre plus robuste, vous pouvez créer des courants d'enregistrement.propriétés et log4j.les propriétés des fichiers afin de mieux définir vos configurations de journalisation.

Ajouter les lignes ci-dessous dans le fichier de propriétés log4j et il ferme le http journaux :- log4j.enregistreur.org.apache.http=OFF

J'ai eu ce même problème lors de l'exécution jwebunit des tests d'intégration. Je l'ai fixée par l'exclusion de logback et en ajoutant slf4j-log4j12, comme suit:

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

J'ai également le même problème. L'intégralité de la console a été rempli avec [main] DEBUG org.apache.http.wire lors de l'exécution de tests.

La solution qui a fonctionné pour moi a été la création d'un logback-test.xml
src/test/resources/logback-test.xml comme dans https://github.com/bonigarcia/webdrivermanager-examples/blob/master/src/test/resources/logback-test.xml (ref - https://github.com/bonigarcia/webdrivermanager/issues/203)

Pour voir mes journalisation des infos, j'ai remplacé le nom de l'enregistreur="io.github.bonigarcia" avec mon nom de package

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

J'ai rencontré ce problème après la mise HttpComponentsClientHttpRequestFactory pour mon repos modèle.

Réglage OkHttpClientHttpRequestFactory devrait résoudre le problème avec la corbeille de journalisation.

J'ai essayé toutes les solutions ci-dessus, en vain. Une soution qui est plus proche pour moi a été l'un suggérant la création d'un logback.xml. Qui a travaillé, cependant rien n'a été enregistré. Après avoir joué avec les logback.xml, c'est ce que j'ai fini avec

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

Maintenant Tous les niveaux en dessous de DÉBOGAGE seront consignées correctement.

Dans mon cas, j'utilise xml de configuration, et j'ai ajouter ceci dans le fichier de configuration

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