Désactiver la journalisation HttpClient


134

J'utilise commons-httpclient 3.1 dans une suite de tests d'intégration. La journalisation par défaut pour HttpClient est extrêmement bruyante et je n'arrive pas à la désactiver. J'ai essayé de suivre les instructions ici, mais aucune d'elles ne fait de différence.

La plupart du temps, j'ai juste besoin de fermer l'enregistreur org.apache.http.wire. Une partie du problème est que je ne sais pas quel type d'enregistreur HttpClient essaie d'utiliser et la plupart du problème est que je n'ai jamais utilisé cette bibliothèque auparavant. J'ai essayé de créer un fichier log4j.properties et de le déposer dans mon dossier test / resources, en modifiant le fichier master logging.properties dans jre / lib et en envoyant les différentes options de journalisation à Maven comme spécifié sur la page de journalisation , et aucune d'entre elles faire une différence.

Toute aide est appréciée ... cela me rend fou.

MISE À JOUR: Une correction: il semble que la sortie en question provient en fait de l'utilisation de HttpClient par jwebunit, pas de la mienne. Quoi qu'il en soit, ce n'est pas souhaitable.

MISE À JOUR: Merci pour les tentatives jusqu'à présent. J'ai essayé tout ce qui est suggéré ci-dessous mais toujours pas de chance. J'ai un fichier commons-logging.properties dans mon dossier src / test / resources avec le contenu suivant

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

et un fichier log4j.properties dans le même dossier avec le contenu suivant

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

Cependant, lorsque j'exécute mes tests, j'obtiens toujours un tas de résultats comme celui-ci:

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

Cette sortie pour tout ce qui passe sur le fil rend cette bibliothèque inutilisable pour moi ... jusqu'à ce que je puisse comprendre comment la désactiver. Dois-je faire quelque chose de spécial pour que cette configuration de journal soit lue?


Pour tous ceux qui rencontrent ce problème: assurez-vous d'ajouter des -Dlog4j.debugoptions à votre machine virtuelle pour vous assurer que le bon fichier de configuration est chargé
Tommy

3
Voir stackoverflow.com/questions/1436761/… . Extrait: public class Main { static { System.setProperty("org.apache.commons.logging.Log", "org.apache.commons.logging.impl.NoOpLog"); } // Rest of class as before }
PVS du


3
Cela a-t-il déjà été résolu pour OP. Ce problème exact me tue.
Collin Bell

2
Est-ce résolu? J'ai essayé d'attribuer les réponses, pas de chance.
Markvds

Réponses:


85

Mettre log4j.propertiesà jour pour inclure:

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

Notez que si la bibliothèque Log4j n'est pas installée, HttpClient (et par conséquent JWebUnit) utilisera le retour de session. Dans cette situation, créez ou modifiez logback.xmlpour inclure:

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

La définition du niveau de journalisation WARNavec Log4j en utilisant le nom du package org.apache.commons.httpclientdans log4j.properties ne fonctionnera pas comme prévu:

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

En effet, la source de HttpClient (v3.1) utilise les noms de journal suivants:

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

19
Dans la source 4.2.1, les noms de journaux sont: "org.apache.http.headers" et "org.apache.http.wire", même si même en les utilisant, la journalisation apache bruyante ne semble pas s'arrêter pour moi .
Tinclon

Je vous remercie!!! Aussi: Si vous rencontrez ce problème quelque part dans votre propre code, où vous utilisez httpclient et que vous n'utilisez pas déjà Log4j: N'oubliez pas également d'inclure le fichier jar log4j dans le
chemin de classe

30

Remarque: une partie de cette réponse peut répéter des choses que vous savez déjà (ou pensez savoir), mais il y a un peu de fausses informations flottant autour de cette question, donc je vais commencer par le début et tout préciser

  • Commons HttpClient utilise Commons-Logging pour tous ses besoins de journalisation.
  • Commons-Logging n'est pas un cadre de journalisation complet, mais plutôt un wrapper autour de plusieurs cadres de journalisation existants
  • Cela signifie que lorsque vous souhaitez contrôler la sortie de journalisation, vous finissez (principalement) par configurer une bibliothèque autre que Commons-Logging, mais comme Commons-Logging englobe plusieurs autres bibliothèques, il nous est difficile de deviner laquelle configurer sans le savoir. votre configuration exacte.
  • Commons-Logging peut se connecter à log4j, mais il peut également se connecter java.util.logging(journalisation JDK1.4)
  • Commons-Logging essaie d'être intelligent et de deviner quel cadre de journalisation vous utilisez déjà, et d'envoyer ses journaux à cela.
  • Si vous ne disposez pas déjà d'un cadre de journalisation et que vous utilisez un JRE de version 1.4 ou supérieure (ce que vous devriez vraiment être), il enverra probablement ses messages de journal à la journalisation JDK ( java.util.logging)
  • Se fier au mécanisme de découverte automatique de Commons-Logging est sujet à des erreurs. Le simple fait d'ajouter log4j.jarau classpath le ferait changer le mécanisme de journalisation qu'il utilise, ce qui n'est probablement pas ce que vous voulez
  • Il est préférable que vous indiquiez explicitement à Commons-Logging quelle bibliothèque de journalisation utiliser
  • Vous pouvez le faire en créant un commons-logging.propertiesfichier selon ces instructions
  • Les étapes à suivre pour configurer la journalisation commons-httpclient sont
    1. Décidez du cadre de journalisation sous-jacent que vous souhaitez utiliser. Il y a un certain nombre de choix, mais probablement log4jou java.util.loggingsont les meilleures options pour vous.
    2. Configurez le fichier de propriétés de journalisation des communs pour qu'il pointe vers l' Logimplémentation correcte . par exemple pour utiliser log4j, placez ceci dans le fichier de propriétés:, org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLoggerou pour utiliser le jeu de journalisation JDK org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger. Ceux-ci peuvent également être définis comme propriétés système (par exemple en utilisant -Dsur la ligne de commande).
    3. Configurez l'implémentation de journalisation sous-jacente (par exemple log4j) pour ignorer les messages que vous ne voulez pas, et sortez les messages que vous voulez.

C'est beaucoup d'étapes, mais c'est ce qu'il faut. Les développeurs d'Apache-commons ont tendance à supposer que vous avez déjà configuré un cadre de journalisation et qu'ils peuvent déterminer lequel il s'agit par découverte automatique.
Si ce n'est pas le cas pour vous, il vous faudra un peu plus de travail pour faire fonctionner les choses.


1
C'est une information très utile; J'ai vraiment l'impression qu'il devrait être ajouté à cette page . L'avez-vous écrit juste pour ça?
natem345

1
Mec, cette réponse est excellente, mais je n'ai pas réussi à la faire fonctionner. J'utilise Dropwizard, et j'ai essayé tout ce que vous avez mentionné, en vain: '(
Vic Seedoubleyew

19

Je mets ceci dans mon fichier de configuration log4j

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

Cela limite la sortie au niveau d'avertissement ou supérieur


19

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

18

Pour log4j, ajoutez ce qui suit à log4j.properties(dans le sourcerépertoire de l'application ):

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

Pour la connexion, ce qui suit logback.xmltuera le bruit:

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

1
J'utilise log4j. L'ajout des deux premières lignes dans le solveur de journal mon problème complètement. Tous mes autres messages de journal apparaissent en fonction du niveau que j'ai défini. Alors que les journaux Apache ne le font pas. Grande aide. Merci.
Arun Thundyill Saseendran

Cela variera probablement en fonction de votre situation, mais pour désactiver la journalisation terriblement verbeuse activée prête à l'emploi avec le SDK AWS, c'est la seule qui a fonctionné.
Matt Baker le

11

Cela a pris beaucoup trop de temps pour le découvrir, mais JWebUnit est livré avec le composant de journalisation Logback , il n'utilisera donc même pas log4j.propertiesoucommons-logging.properties .

Au lieu de cela, créez un fichier appelé logback.xmlet placez-le dans votre dossier de code source (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 en train de changer, donc cet exemple de code peut échouer à l'avenir. Voir également cette question StackOverflow .


1
Toi beauté. J'ai failli tuer un chat à cause de cette chose. Cela me rendait fou.
Manish Patel

C'était la solution pour moi. Je pense que c'est parce que d'autres bibliothèques que j'incluais de manière transitoire incluaient un retour de connexion, donc il s'est verrouillé sur cet enregistreur.
Nathan

10

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

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

    //...
}

2
Fantastique, la seule solution qui a fonctionné pour moi. Merci beaucoup.
lasote

Je vous remercie! Utilisait exactement le même code au début de la méthode de test, n'a rien fait. Le placer dans son propre @Beforeou sa @BeforeClassfonction a fonctionné à merveille.
ExactaBox

8

Nous utilisons XML, plutôt qu'un fichier de propriétés, pour configurer notre sortie de journalisation. Le code suivant a fonctionné pour faire taire ce bavardage.

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

4

Dans votre log4.properties - avez-vous cet ensemble comme je le fais ci-dessous et aucun autre org.apache.httpenregistreur n'est défini dans le fichier?

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

De plus, si aucun niveau de journal n'est spécifié org.apache.httpdans votre fichier de propriétés log4j, il héritera du log4j.rootLoggerniveau. Donc, si vous avez log4j.rootLoggerdéfini, disons ERROR, et supprimez les org.apache.httpparamètres de votre log4j.properties, cela devrait lui permettre de ne consigner les ERRORmessages que par héritage.

METTRE À JOUR:

Créez un commons-logging.propertiesfichier et ajoutez-y la ligne suivante. Assurez-vous également que ce fichier est dans votre CLASSPATH.

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

Ajout d'un fichier log4j terminé et du code pour l'invoquer pour l'OP. Ce log4j.properties doit être dans votre CLASSPATH. Je suppose stdout pour le moment.

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

Voici du code que vous devez ajouter à votre classe pour appeler le logger.

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
}

Je n'avais pas besoin d'un fichier log4j.properties avant d'essayer d'utiliser HttpClient. J'ai essayé de mettre vos lignes dans mon fichier src / test / resources / log4j.properties mais cela ne faisait aucune différence. Est-il même juste de mettre les options commons.logging dans log4j.properties?
Matt Baker

Ouais, la journalisation des communs est juste une enveloppe autour de log4j. Comment invoquez-vous le logger dans votre classe de test?
CoolBeans

(Après votre mise à jour) J'ai fait en sorte que la ligne ci-dessus soit la seule de mon fichier log4j.properties et qu'elle crache toujours tout.
Matt Baker

1
Je n'invoque pas le logger, HttpClient le fait tout seul.
Matt Baker

Il indique sur le lien que vous avez fourni que - "Remarque: Log4j n'est pas inclus dans la distribution HttpClient." Vous devez donc absolument l'ajouter à votre CLASSPATH. Voyez-vous la sortie dans stdout (console) ou dans un fichier journal? Je vais créer un exemple de fichier log4h avec du code pour l'invoquer pour vous.
CoolBeans

4

Manière simple Log4j et HttpCLient (v3.1 dans ce cas, devrait fonctionner pour une version supérieure, pourrait nécessiter des modifications mineures)

Assurez-vous que toutes les dépendances sont correctes, et MD5 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();

Dois-je le mettre en mainméthode?
parsecer

@parsecer you can
WiR3D

4

Je suis en proie au même problème depuis un certain temps maintenant et j'ai finalement décidé de me pencher sur la question. Il s'est avéré que le problème était que mon projet avait une dépendance sur http-builder-0.5.2.jar qui regroupait un fichier log4j.xml en lui-même. Et bien sûr, le niveau de journalisation de org.apache.http.wire était DEBUG! La façon dont je l'ai trouvé était juste de parcourir tous les fichiers jar de mes dépendances et de faire "jar tvf" et grepping pour log4j.

Bien que cette découverte ait conduit à la solution éventuelle d'augmenter la version de ma dépendance http-builder à 0.6, cela me déroute toujours ce qui a dû passer par l'esprit du développeur lors du regroupement du fichier log4j.xml dans le fichier jar. Quoi qu'il en soit, ce n'est probablement pas pertinent pour ce fil pour le moment. Mais j'ai pensé qu'il était utile de mentionner cette solution que j'ai trouvée étant donné que lorsque je cherchais une solution auparavant, la mienne ne s'est jamais présentée. J'espère que quelqu'un trouvera cela utile.


Problème similaire lors de l'utilisation <!-- 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>. Suppression de la dépendance et les journaux ont disparu. Je vous remercie!
Adom

3

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

  • bocaux Logback supprimés
  • ajouter la bibliothèque de pont lod4j pour sfl4j - slf4j-log4j12-1.6.4.jar
  • ajouter log4j.properties

Vous n'avez probablement pas à supprimer les fichiers jar Logback, mais vous aurez besoin d'une étape supplémentaire pour forcer slf4j à utiliser log4j


Merci, j'ai eu le même problème lors de l'utilisation d'OpenRdf. Tous les autres conseils de ce fil semblent n'avoir aucun effet jusqu'à ce que je supprime les bocaux de connexion, maintenant le journal est bien silencieux.
amarillion

3

Les 2 lignes suivantes ont complètement résolu mon problème:

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

Cela a fonctionné pour moi aussi, mais je n'avais pas besoin de: Logger.getLogger ("org.apache.commons.httpclient"). SetLevel (Level.ERROR);
Jamel Toms

3

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


dans les tests unitaires (si main, puis en main), ajoutez également le @BeforeClass public static void BeforeClass() { PropertyConfigurator.configure("log4j.properties"); ...}fichier log4j.properties avec la seule ligne log4j.logger.org.apache.http = OFF devrait être à la racine (juste au-dessus du dossier src)
Sasha Bond

3

J'avais aussi le même problème. La console entière était remplie [main] DEBUG org.apache.http.wirelors de l'exécution des tests.

La solution qui a fonctionné pour moi a été de créer 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 (réf - https://github.com/bonigarcia/webdrivermanager/issues/203 )

Pour afficher mes informations de journalisation, j'ai remplacé logger name = "io.github.bonigarcia" par le nom de mon 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>

2

J'ai été amené à ce poste lors de la recherche d'une solution à un problème similaire. La réponse de Tim a été très utile. comme Matt Baker, je veux juste fermer le journal httpClient sans trop de configuration. Comme nous ne savions pas quelle implémentation de journalisation sous Common-logging était utilisée, ma solution était de la forcer à utiliser log4j en lançant le fichier jar log4j dans le chemin de classe. Le paramètre par défaut de la configuration log4j arrête la sortie de débogage common-httpclient. Bien sûr, pour le rendre plus robuste, vous pouvez créer des fichiers common-logging.properties et log4j.properties pour définir davantage vos configurations de journalisation.


2

Essayez de mettre

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

dans votre commons-logging.properties


2

Pour apache 4.5.3, si vous souhaitez déplacer le niveau de toutes les journalisations du client http apache vers Warn , utilisez:

log4j.logger.org.apache=WARN

2

cela fonctionne pour moi avec ajouter "logback.xml" dans le chemin racine de la classe et en dessous du paramètre.

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

1

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

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

1

Cela m'a pris du temps à comprendre une fois, vous en avez besoin:

log4j.logger.httpclient.wire=ERROR

Je suppose que HttpClient utilise "httpclient.wire" comme nom d'enregistreur, et non "org.apache.commons.httpclient".

Buggers sournois.


1

Cela a fonctionné pour moi.

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

0

La meilleure solution que j'ai trouvée était d'utiliser le plugin maven enforcer afin d'éviter que la journalisation des communs ne soit complètement utilisée. Ensuite, j'ai ajouté la dépendance slf4j pour la journalisation à la place. Alors ajoutez ce qui suit à votre pom.xml

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

et ajoutez également le plugin maven-enforcer

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

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

J'ai rencontré un tel problème après avoir défini HttpComponentsClientHttpRequestFactory pour mon modèle de repos.

La configuration de OkHttpClientHttpRequestFactory devrait résoudre le problème de journalisation de la corbeille.


0

Ajoutez simplement ces deux dépendances dans le fichier pom: j'ai essayé et réussi après avoir essayé la discussion avant.

<!--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 et informations par défaut pendant que le débogage ne sera pas présent; Vous pouvez utiliser:

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

pour définir les informations que vous souhaitez enregistrer: comme Résultat final comme ceci. Seules les informations que je souhaite enregistrer seront présentes.


0

J'ai essayé toutes les solutions ci-dessus en vain. La solution la plus proche pour moi était celle suggérant de créer un logback.xml. Cela a fonctionné, mais rien n'a été enregistré. Après avoir joué avec le 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>

Désormais, tous les niveaux inférieurs à DEBUG sont correctement enregistrés.


0

Avec:

  • Log2J 2 2.11.2
  • HttpClient 4.5.7 (client de repos elasticsearch 7.0.0)
  • Utilisation du fichier de propriétés pour configurer

On peut ajouter:

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

Avec 'httpclient' dans l'exemple ci-dessus étant un nom logique que vous choisissez.

(Testé sur l'application Java 11 OpenFX.)


0

Dans mon cas, j'utilise la configuration xml, et je l'ajoute au fichier de configuration

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


0

Pour moi, les lignes ci-dessous dans le fichier prop log4j ont nettoyé tous ces dégâts qui provenaient de la journalisation HttpClient ... Hourra !!! :)

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
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.