Desativar log HttpClient

Estou usando o commons-httpclient 3.1 em um conjunto de testes de integração. O log padrão do HttpClient é extremamente barulhento e não consigo desativá-lo. Tentei seguir as instruções aqui, mas nenhuma delas faz diferença.

Principalmente, só preciso fazer o log do org.apache.http.wire calar a boca. Parte do problema é que não sei que tipo de agente de log o HttpClient está tentando usar e a maior parte do problema é que nunca usei essa biblioteca antes. Tentei criar um arquivo log4j.properties e soltá-lo na minha pasta test / resources, modificar o arquivo master logging.properties no jre / lib e enviar as várias opções de log para o Maven, conforme especificado na página de log , e nenhuma delas faça alguma diferença.

Qualquer ajuda é apreciada ... isso está me deixando louco.

UPDATE: Uma correção: parece que a saída em questão está realmente originada pelo uso do HttpClient pelo jwebunit, não pelo meu. De qualquer forma, não é desejável.

ATUALIZAÇÃO: Obrigado pelas tentativas até agora. Eu tentei de tudo sugerido abaixo, mas ainda sem sorte. Eu tenho um arquivo commons-logging.properties na minha pasta src / test / resources com o seguinte conteúdo

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

e um arquivo log4j.properties na mesma pasta com o seguinte conteúdo

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

No entanto, quando executo meus testes, ainda recebo um monte de resultados como este:

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

Essa saída para tudo o que ocorre através do fio está tornando essa biblioteca inutilizável para mim ... ou seja, até que eu possa descobrir como desativá-la. Preciso fazer algo especial para ler essa configuração de log?

Atualize log4j.propertiespara incluir:

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

Observe que, se a biblioteca Log4j não estiver instalada, o HttpClient (e, portanto, o JWebUnit) usará o logback. Nessa situação, crie ou edite logback.xmlpara incluir:

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

Definir o nível de log WARNcom Log4j usando o nome do pacote org.apache.commons.httpclientin log4j.properties não funcionará conforme o esperado:

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

Isso ocorre porque a origem do HttpClient (v3.1) usa os seguintes nomes de log:

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

Nota: Algumas dessas respostas podem repetir coisas que você já sabe (ou acha que sabe), mas há algumas informações erradas sobre essa questão, por isso vou começar do início e explicar tudo

• O Commons HttpClient usa o Commons-Logging para todas as suas necessidades de registro.
• O Commons-Logging não é uma estrutura de registro completa, mas sim um invólucro em torno de várias estruturas de registro existentes
• Isso significa que, quando você deseja controlar a saída do registro, você (principalmente) acaba configurando uma biblioteca diferente do Commons-Logging, mas como o Commons-Logging envolve várias outras bibliotecas, é difícil adivinhar qual configurar sem saber sua configuração exata.
• O Commons-Logging pode efetuar logon no log4j, mas também pode fazer logon no java.util.logging efetuar (log JDK1.4)
• O Commons-Logging tenta ser inteligente e adivinhar qual estrutura de registro você já está usando e enviar seus registros para isso.
• Se você ainda não possui uma estrutura de log e está executando em um JRE que é 1.4 ou superior (o que realmente deveria ser), provavelmente enviará suas mensagens de log para o log do JDK (java.util.logging )
• Confiar no mecanismo de descoberta automática do Commons-Logging é propenso a erros. Simplesmente adicionar log4j.jarno caminho de classe faria com que ele alternasse qual mecanismo de log ele usa, o que provavelmente não é o que você deseja
• É preferível informar explicitamente ao Commons-Logging qual biblioteca de log usar
• Você pode fazer isso criando um commons-logging.propertiesarquivo conforme estas instruções
• As etapas que você deseja seguir para configurar o log do commons-httpclient são
  1. Decida qual estrutura de log subjacente você deseja usar. Existem várias opções, mas provavelmente log4jou java.util.loggingsão as melhores opções para você.
  2. Configure o arquivo de propriedades do log comum para apontar para a Logimplementação correta . por exemplo, para usar o log4j, coloque-o no arquivo de propriedades:, org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLoggerou para usar o conjunto de logs do JDK org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger. Eles também podem ser definidos como propriedades do sistema (por exemplo, usando -Dna linha de comando).
  3. Configure a implementação de log subjacente (por exemplo, log4j) para ignorar as mensagens que você não deseja e envie as mensagens que deseja.

São muitos passos, mas é o que é preciso. Os desenvolvedores do Apache-commons tendem a supor que você já possui uma estrutura de log configurada e podem descobrir qual é por descoberta automática.
Se isso não é verdade para você, então tende a ser um pouco mais trabalhoso para fazer as coisas funcionarem.

Coloquei isso no meu arquivo de configuração log4j

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

Isso limita a saída ao nível de aviso ou acima

Isso funcionou para os meus testes;

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

Para log4j, adicione o seguinte a log4j.properties(no sourcediretório do aplicativo ):

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

Para o logback, o seguinte logback.xmlirá eliminar o ruído:

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

Demorou muito tempo para descobrir isso, mas o JWebUnit vem com o componente de log Logback , portanto, ele nem usa log4j.propertiesnemcommons-logging.properties .

Em vez disso, crie um arquivo chamado logback.xmle coloque-o na sua pasta de código-fonte (no meu caso 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>

O logback ainda parece estar em desenvolvimento e a API ainda parece estar mudando; portanto, esse exemplo de código pode falhar no futuro. Veja também esta pergunta StackOverflow .

Eu tive esse problema ao usar o RestAssured com JUnit. Para mim, essa abordagem programática funcionou:

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

    //...
}

Usamos XML, em vez de um arquivo de propriedades, para configurar nossa saída de log. O código a seguir trabalhou para silenciar essa conversa.

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

Em seu log4.properties - você tem esse conjunto como eu abaixo e nenhum outro org.apache.httplogger definido no arquivo?

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

Além disso, se você não tiver nenhum nível de log especificado org.apache.httpno arquivo de propriedades log4j, ele herdará o log4j.rootLoggernível. Portanto, se você log4j.rootLoggerconfigurou para, digamos, ERROR e org.apache.httpefetue as configurações em seu log4j.properties, que devem torná-lo apenas para registrar ERRORmensagens apenas por herança.

ATUALIZAR:

Crie um commons-logging.propertiesarquivo e adicione a seguinte linha. Verifique também se esse arquivo está no seu CLASSPATH.

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

Adicionado um arquivo log4j completo e o código para invocá-lo para o OP. Este log4j.properties deve estar em seu CLASSPATH. Estou assumindo stdout no momento.

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

Aqui está um código que você precisa adicionar à sua classe para chamar o criador de logs.

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
}

Maneira simples Log4j e HttpCLient (v3.1, neste caso, deve funcionar para maiores, pode exigir pequenas alterações)

Verifique se todas as dependências estão corretas, e MD5 seus 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();

Fui atormentado pelo mesmo problema há algum tempo e finalmente decidi investigar isso. O problema é que meu projeto dependia do http-builder-0.5.2.jar, que incluía um arquivo log4j.xml em si. E, com certeza, o nível de log para org.apache.http.wire foi DEBUG! A maneira que eu achei foi apenas passar por todos os arquivos jar em minhas dependências e fazer "jar tvf" e grepping para log4j.

Embora essa descoberta tenha levado à eventual solução de aumentar a versão da minha dependência do http-builder para 0,6, ela ainda me confunde o que deve ter passado pela mente do desenvolvedor ao agrupar o arquivo log4j.xml no arquivo jar. De qualquer forma, isso provavelmente não é relevante para este tópico no momento. Mas achei útil mencionar essa solução que encontrei, pois quando eu estava procurando uma solução antes, a minha nunca surgiu. Espero que alguém ache isso útil.

Eu tive o mesmo problema com o JWebUnit. Observe que, se você usar distribuição binária, o Logback será um logger padrão. Para usar o log4j com o JWebUnit, executei as seguintes etapas:

• jarros de Logback removidos
• adicionar biblioteca de ponte lod4j para sfl4j - slf4j-log4j12-1.6.4.jar
• adicione log4j.properties

Provavelmente você não precisa remover os frascos do Logback, mas precisará de alguma etapa adicional para forçar o slf4j a usar o log4j

As 2 linhas a seguir resolveram meu problema completamente:

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

Adicione as linhas abaixo no arquivo de propriedades log4j e ele fechará os logs http: - log4j.logger.org.apache.http = OFF

Eu também estava tendo o mesmo problema. Todo o console estava cheio de[main] DEBUG org.apache.http.wire durante a execução dos testes.

A solução que funcionou para mim foi criar um logback-test.xml src / test / resources / logback-test.xml como em https://github.com/bonigarcia/webdrivermanager-examples/blob/master/src/test/resources /logback-test.xml (ref - https://github.com/bonigarcia/webdrivermanager/issues/203 )

Para visualizar minhas informações de log, substitui logger name = "io.github.bonigarcia" pelo nome do meu pacote

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

Fui levado a este post ao procurar uma solução para um problema semelhante. A resposta de Tim foi muito útil. como Matt Baker, eu só quero desligar o log httpClient sem muita configuração. Como não tínhamos certeza de qual implementação de log abaixo do log comum foi usada, minha solução foi forçá-lo a usar o log4j jogando o arquivo jar log4j no caminho da classe. A configuração padrão da configuração do log4j desliga a saída de depuração do common-httpclient. Obviamente, para torná-lo mais robusto, você pode criar arquivos common-logging.properties e log4j.properties para definir melhor suas configurações de log.

Tente colocar

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

em seu commons-logging.properties

Para o apache 4.5.3, se você deseja mover o nível de todos os logs do cliente http do apache para Warn , use:

log4j.logger.org.apache=WARN

é um trabalho para mim adicionar "logback.xml" no caminho raiz da classe e abaixo da configuração.

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

Eu tive esse mesmo problema ao executar testes de integração do jwebunit. Corrigi-o excluindo o logback e adicionando o slf4j-log4j12, assim:

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

Levei séculos para descobrir uma vez, você precisa disso:

log4j.logger.httpclient.wire=ERROR

Eu acho que o HttpClient usa "httpclient.wire" como o nome do criador de logs, não "org.apache.commons.httpclient".

Buggers sorrateiros.

Isso funcionou para mim.

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

A melhor solução que encontrei foi usar o plug-in maven enforcer para impedir que o log comum fosse usado por completo. Em seguida, adicionei a dependência do slf4j para o log. Portanto, adicione o seguinte ao seu pom.xml

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

e também adicione o plug-in 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>

Tive esse problema depois de definir HttpComponentsClientHttpRequestFactory para o meu modelo de descanso.

Definir OkHttpClientHttpRequestFactory deve resolver o problema com o log de lixo.

Simplesmente adicione estas duas dependências no arquivo pom: Eu tentei e consegui depois de tentar a discussão anterior.

<!--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 e Informações padrão enquanto a Depuração não estiver presente; Você pode usar:

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

para definir as informações que você deseja registrar: como resultado final como este. Somente as informações que eu quero registrar estarão presentes.

Eu tentei todas as soluções acima sem sucesso. A alma que mais me aproximou foi a que sugeria a criação de um logback.xml. Isso funcionou, mas nada foi registrado. Depois de brincar com o logback.xml, foi com isso que acabei

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

Agora, todos os níveis abaixo de DEBUG são registrados corretamente.

Com:

• Log2J 2 2.11.2
• HttpClient 4.5.7 (cliente de descanso elasticsearch 7.0.0)
• Usando o arquivo de propriedades para configurar

Pode-se adicionar:

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

Com 'httpclient' no exemplo acima, sendo um nome lógico, você escolhe.

(Testado no aplicativo Java 11 OpenFX.)

No meu caso, eu uso a configuração xml e anexo ao arquivo de configuração

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

Tente 'log4j.logger.org.apache.http.headers = ERRO'

Para mim, as linhas abaixo no arquivo log4j prop limparam toda a bagunça que vinha do log do HttpClient ... Hurrah !!! :)

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