Disable HttpClient logging

Question

I´m using commons-httpclient 3.1 in an integration test suite. The default logging for HttpClient is extremely noisy and I can't seem to turn it off. I've tried following the instructions here but none of them make any difference.

Mostly I just need to make the org.apache.http.wire logger shut up. Part of the problem is that I don't know what type of logger HttpClient is trying to use. I've never used this library before. I tried creating a log4j.properties file and dropping it in my test/resources folder, modifying the master logging.properties file in jre/lib, and sending in the various logging options to Maven as specified on the logging page, and none of them make any difference.

UPDATE: A correction: it appears the output in question is actually originating through jwebunit's usage of HttpClient, not my own. Either way, it's not desirable.

UPDATE: Thanks for the attempts so far. I've tried everything suggested below but still no luck. I have a file commons-logging.properties in my src/test/resources folder with the following contents

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

and a file log4j.properties in the same folder with the following contents

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

However, when I run my tests I still get a bunch of output like this:

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

This output for everything that comes across the wire is making this library unusable for me...that is until I can figure out how to turn it off. Is there anything special I need to do to get this log configuration read in?

Selfsupporting

For all coming across this problem: make sure to add -Dlog4j.debug to your VM options to ensure that the right config file is loaded – Growl

See #1437261. To excerpt: public class Main { static { System.setProperty("org.apache.commons.logging.Log", "org.apache.commons.logging.impl.NoOpLog"); } // Rest of class as before } – Erelia

Official doc: hc.apache.org/httpclient-3.x/logging.html – Fungus

Did this ever get solved for OP. This exact problem is killing me. – Nitrobenzene

Is this solved? Tried allot of the answers, no luck. – Zealous

Holy crap. This made me go back to HttpURLConnection – Hornbeam

Answer 1

Update log4j.properties to include:

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

---

Note that if Log4j library is not installed, HttpClient (and therefore JWebUnit) will use logback. In this situation, create or edit logback.xml to include:

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

---

Setting the log level to WARN with Log4j using the package name org.apache.commons.httpclient in log4j.properties will not work as expected:

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

This is because the source for HttpClient (v3.1) uses the following log names:

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

Nakano

In the 4.2.1 source, the log names are: "org.apache.http.headers" and "org.apache.http.wire", though even using them, the noisy apache logging won't seem to shut off for me. – Neptunium

Thank you!!! Also: If you have this issue somewhere in your own code, where you use httpclient and don't already use Log4j: Also remember to include the log4j jar in the classpath ... – Brow

Hi, how should we do with the xml config file for log4j, thanks. – Scrape

Answer 2

Note: Some of this answer might repeat things you already know (or think you know), but there is a bit of mis-information floating around on this question, so I'm going to start at the beginning and spell it all out

• Commons HttpClient uses Commons-Logging for all its logging needs.

• Commons-Logging is not a full logging framework, but rather, is a wrapper around several existing logging frameworks

• That means that when you want to control the logging output, you (mostly) end up configuring a library other than Commons-Logging, but because Commons-Logging wraps around several other libraries, it's hard for us to guess which one to configure without knowing your exactly setup.

• Commons-Logging can log to log4j, but it can also log to java.util.logging (JDK1.4 logging)

• Commons-Logging tries to be smart and guess which logging framework you are already using, and send its logs to that.

• If you don't already have a logging framework, and are running on a JRE that's 1.4 or above (which you really should be) then it will probably be sending its log messages to the JDK logging (java.util.logging)

• Relying on Commons-Logging's autodiscovery mechanism is prone to error. Simply adding log4j.jar onto the classpath would cause it to switch which logging mechanism it uses, which probably isn't what you want

• It is preferable for you to explicitly tell Commons-Logging which logging library to use

• You can do this by creating a commons-logging.properties file as per these instructions

• The steps you want to follow to configure the commons-httpclient logging are

• Decide which underlying logging framework you want to use. Historically, the common choices used to be log4j or java.util.logging. In 2022, the common choice is LogBack (also the Spring Framework's default).

• Set-up the commons-logging properties file to point to the correct Log implementation. e.g.:
  To use log4j, put this into the properties file:
  org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger
  To use JDK logging set:
  org.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger.
  To use Slf4J:
  org.apache.commons.logging.Log=org.apache.logging.slf4j.SLF4JLogger

  These can also be set as system properties (e.g. using -D on the command line).

3. Configure the underlying logging implementation (e.g. log4j) to ignore the messages you don't want, and output the messages you do want.

That's a lot of steps, but that's what it takes. The developers at Apache-commons tend to assume you'll already have a logging framework configured, and they can work out which one it is by auto-discovery.
If that's not true for you, then it tends to be a bit more work to get things running.

Haste

This is very useful information; I really feel like it should be added to this page. Did you write it just for this? – Morville

Man, this answer is great, but I failed to make it work. I am using Dropwizard, and I tried everything you mentioned, to no avail :'( – Coldblooded

Answer 3

For log4j, add the following to log4j.properties (in the application's source directory):

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

For logback, the following logback.xml will kill the noise:

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

Spermicide

I am using log4j. Adding the first two lines in the log solver my problem completely. All my other log messages appear according to the level I set. Whereas apache logs doesn't. Great help. Thanks. – Alcoholism

It will likely vary depending on your situation, but for disabling the terribly verbose logging enabled out of the box with the AWS SDK, this is the only one that worked. – Selfsupporting

Answer 4

This worked for my 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");

Taranto

Did you place this in tests? – Duumvir

Answer 5

I put this into my log4j config file

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

This limits the output to Warning level or above

Jetsam

Answer 6

I had this issue while using RestAssured with JUnit. For me this programmatic approach worked:

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

    //...
}

Reliance

Fantastic, the only solution it worked for me. Thanks so much. – Bogusz

Thank you! Was using the exact same code at the start of the test method, did nothing. Placing it in its own @Before or @BeforeClass function worked beautifully. – Petie

Only solution that worked for me. Initiated this inside WebApplicationInitializer. – Popcorn

This is what you need if you're just running a local test from a main method :) thanks! – Turley

Answer 7

It took far too long to find this out, but JWebUnit comes bundled with the Logback logging component, so it won't even use log4j.properties or commons-logging.properties.

Instead, create a file called logback.xml and place it in your source code folder (in my case, 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 looks to still be under development and the API seems to still be changing, so this code sample may fail in the future. See also this StackOverflow question.

Reamonn

You beauty. I almost killed a cat because of this thing. It was driving me insane. – Confirmatory

This was the solution for me. I think its because other libraries I was including transitively included logback, so it got locked onto this logger. – Humorist

Answer 8

We use XML, rather than a properties file, to configure our logging output. The following code worked to silence this chatter.

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

Burgrave

Answer 9

Simple way Log4j and HttpCLient (v3.1 in this case, should work for higher, could require minor changes)

Make sure all the dependencies are correct, and MD5 your 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();

Anticlockwise

Should I place it in main method? – Laterality

@Laterality you can – Anticlockwise

Answer 10

It may be caused by a dependency bringing in a logging config (which they really should not, unless it's a framework supposed to do so).

I've been plagued by the same issue for quite some time now and finally decided to look into this.

It turned out the issue is that my project had a dependency on http-builder-0.5.2.jar which bundled a log4j.xml file within itself. And sure enough, the log level for org.apache.http.wire was DEBUG! The way I found it was just to go through all the jar files in my dependencies and do "jar tvf" and grepping for log4j.

While this discovery led to the eventual solution of upping the version of my http-builder dependency to 0.6, it still baffles me what must have gone through the developer's mind when bundling the log4j.xml file into the jar file. Anyway, that's probably not relevant to this thread for now. But I figured it's useful to mention this solution I found given that when I was searching for a solution before now, mine never came up. Hopefully someone will find this useful.

Histogram

Similar issue while using <!-- 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>. Removed the dependency and logs were gone. Thank you! – Mottle

Answer 11

I was also having the same problem. The entire console was filled with [main] DEBUG org.apache.http.wire while running the tests.

The solution which worked for me was creating a logback-test.xml src/test/resources/logback-test.xml as in https://github.com/bonigarcia/webdrivermanager-examples/blob/master/src/test/resources/logback-test.xml (ref - https://github.com/bonigarcia/webdrivermanager/issues/203)

To view my logging infos, I replaced logger name="io.github.bonigarcia" with my package name

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

Adviser

I just wonder why you refer to WebDriverManager's test logging config rather than the LogBack documentation. This works because it 1) Sets the root level to INFO, 2) accidentally hits the logger by setting the org logger, which would not work with older HttpClient. – Designedly

Answer 12

it's work for me with add "logback.xml" in class root path and below setting.

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

Aparejo

Answer 13

In your log4.properties - do you have this set like I do below and no other org.apache.http loggers set in the file?

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

Also if you don't have any log level specified for org.apache.http in your log4j properties file then it will inherit the log4j.rootLogger level. So if you have log4j.rootLogger set to let's say ERROR and take out org.apache.http settings in your log4j.properties that should make it only log ERROR messages only by inheritance.

UPDATE:

Create a commons-logging.properties file and add the following line to it. Also make sure this file is in your CLASSPATH.

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

Added a completed log4j file and the code to invoke it for the OP. This log4j.properties should be in your CLASSPATH. I am assuming stdout for the 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

Here is some code that you need to add to your class to invoke the 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
}

Atween

I didn't have a need for a log4j.properties file before trying to use HttpClient. I tried putting your lines in my src/test/resources/log4j.properties file but it didn't make any difference. Is it even right to put commons.logging options in log4j.properties? – Selfsupporting

Yeah commons-logging is just a wrapper around log4j. How do you invoke the logger in your test class? – Atween

(After your update) I made it so that the above line was the only one in my log4j.properties file and it still spits out everything. – Selfsupporting

I don't invoke the logger, HttpClient does it on its own. – Selfsupporting

It says on the link you provided that - "Note: Log4j is not included in the HttpClient distribution." So you definitely need to add it to your CLASSPATH. Are you seeing the output in stdout (console) or in a log file? I will create a sample log4h file with code to invoke it for you. – Atween

the log4j-1.2.14.jar ends up in target\classes\META-INF\lib whenever I build already, along with commons-logging-1.0.4.jar. I feel like this has to be something stupid. – Selfsupporting

Is target\test-classes\log4j.properties in CLASSPATH when my tests run? How can I tell? I added the LogFactory.getLog line to my class but it didn't make any difference, I still get all the noisy HttpClient output... – Selfsupporting

Do you need both log4j and commons-logging? If you invoke the logger like the way I showed in my example it should be using commons-logging. I am not sure why your log4j file ends up in META-INF\lib. Are you just doing mvn install or are you actually doing assemble jar-with-dependencies? – Atween

I'm building a plugin for an Atlassian tool and they appear to follow the MVN conventions in their build folder. When you do an integration-test build it packages your plugin, starts the web application, and deploys your plugin to it. surefire then kicks off your integration tests which interact with the web server. It's the logging output coming out of the integration tests that are killing me. – Selfsupporting

also, it's the log4j JAR file that gets into META-INF\lib. The log4j.properties file goes from src/test/resources into target/test-classes at compile time. – Selfsupporting

The integration test suite is part of your test classes or Atlassian tool ? – Atween

yes, you can view the code here: studio.plugins.atlassian.com/source/browse/EEP/trunk – Selfsupporting

Actually, I think I might be using the more recent documentation. I'm using the "legacy" httpclient whose logging documentation is here: hc.apache.org/httpclient-legacy/logging.html. None of that stuff works either. – Selfsupporting

@Matt - @Haste made a good point. I forgot to add the part to let commons-logging to use log4j. As I said it's a wrapper around what logging implementation being used. I modified my log4j to add that line. Let us know if that made any difference. I think it will. – Atween

This is very context-specific. I do not have Log4J whatsoever, neither the SimpleLog – Designedly

Answer 14

I had the same problem with JWebUnit. Please notice that if you use binary distribution then Logback is a default logger. To use log4j with JWebUnit I performed following steps:

• removed Logback jars
• add lod4j bridge library for sfl4j - slf4j-log4j12-1.6.4.jar
• add log4j.properties

Probably you don't have to remove Logback jars but you will need some additional step to force slf4j to use log4j

Gambier

Thanks, I had the same problem when using OpenRdf. All the other tips in this thread seemed to have no effect until I removed the logback jars, now the log is nicely quiet. – Cassation

Finally someone capable of including applicable context in the answer :) – Designedly

Answer 15

The following 2 lines solved my problem completely:

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

Scrambler

This worked for me too, but I didn't need the: Logger.getLogger("org.apache.commons.httpclient").setLevel(Level.ERROR); – Nyctaginaceous

Ok but what's the Logger? Which API is it from? And what documentation does this follow? And where should it be called? – Designedly

Answer 16

For me, the below lines in the log4j.properties file cleaned up all the mess that came from HttpClient logging... Hurray!!! :)

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

Animatism

Just adding log4j.logger.org.apache.http=INFO should be enough. – Designedly

Answer 17

Add the below lines in the log4j property file and it will shut the http logs :- log4j.logger.org.apache.http=OFF

Lemire

in unit tests (if main, then in main) also add @BeforeClass public static void BeforeClass() { PropertyConfigurator.configure("log4j.properties"); ...} log4j.properties file with the single line log4j.logger.org.apache.http=OFF should be in the root (just above src folder) – Helbonia

It will only do so if you use log4j. – Designedly

Answer 18

I was led to this post when searching for solution for similar problem. Tim's answer was very helpful. like Matt Baker, I just want to shut off httpClient log without too much configuration.

As we were not sure which logging implementation underneath common-logging was used, My solution was to force it using log4j by throwing log4j jar file in the class path. Default setting of log4j configuration shuts off common-httpclient debug output. Of course, to make it more robust, you may create common-logging.properties and log4j.properties files to further define your logging configurations.

Unabridged

"by throwing log4j jar file in the class path" you do not force anything. The frameworks handling logging may decide to prefer other logging implementation, or be configured to use other one. Adding Log4J may actually do more harm than good for frameworks like Spring which prefer LogBack. And adding Log4J just because of it's default config is a very bad reason to do so, instead of setting the config yourself for the logging API / impl which is already in place. – Designedly

Answer 19

Try put

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

in your commons-logging.properties

Smitty

While this may work, it will only work when using Commons Logging (JCL). BUT: It will disable ALL LOGGING WHATSOEVER done through that library. This is a bad solution. – Designedly

Answer 20

For Apache HttpClient 4.5.3, if you want to move the level for all Apache logging to WARN, use:

log4j.logger.org.apache=WARN

Berkey

Use where? Based on what documentation? What does Log4J have to do with it? Please more context. – Designedly

Answer 21

This worked for me.

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

Baal

Where I need to put these sir ? – Bryce

@HikaruShindo this should go in your java code as part of initialization – Baal

Good that it worked for you, but what's the context? Dependencies? Versions? Based on what documentation? Logging should not be configured by throwing in random stuff from StackOverflow. – Designedly

Answer 22

I had this same problem when running jwebunit integration tests. I fixed it by excluding logback and adding in slf4j-log4j12, like so:

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

Padishah

Replacing an entire logging implementation just because not being able to set the loggers is not really solving the problem, and may bring way more problems elsewhere by bringing in a legacy logging framework. – Designedly

Answer 23

This took me ages to figure out once, you need this:

log4j.logger.httpclient.wire=ERROR

I guess HttpClient uses "httpclient.wire" as its logger name, not "org.apache.commons.httpclient".

Sneaky buggers.

Fregoso

We need it where? In which conditions? Based on what docs? Also, httpclient.wire is for the older versions only. The new use org.apache.... – Designedly

This answer is 10 years old. Things might have changed in the meantime... – Fregoso

Answer 24

I experienced such problem after setting HttpComponentsClientHttpRequestFactory for my rest template.

Setting OkHttpClientHttpRequestFactory should solve problem with trash logging.

What

This doesn't "Disable HttpClient logging" but rather entirely replaces Apache HttpClient with OkHttp, which may not support the same features and break other code. Changing a client library just to reduce the logging is not really a good reason. – Designedly

Answer 25

Try 'log4j.logger.org.apache.http.headers=ERROR'

Brent

This answer lacks any context - where to put it? When to use it and when not? – Designedly

Answer 26

For me it was very simple solution :

I had to add log4j dependancies in my POM.xml and that resolved unnecessary loggings .

	  <dependency>
			<groupId>org.apache.logging.log4j</groupId>
			<artifactId>log4j-api</artifactId>
			<version>2.6.1</version>
		</dependency>
		<dependency>
			<groupId>org.apache.logging.log4j</groupId>
			<artifactId>log4j-core</artifactId>
			<version>2.6.1</version>
		</dependency>

Juicy

Thank you. This fixed it for me. Had also to add <dependency> <groupId>org.apache.logging.log4j</groupId> <artifactId>log4j-jcl</artifactId> <version>${log4j.logging.version}</version> </dependency> – Schumann

Answer 27

Since Google also leads here even when searching for a log4j2 solution, here is what you can use. Add the following piece of XML code into your log4j2.xml within the Loggers tags:

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

Working for org.apache.httpcomponents:httpclient:4.5.13 and org.apache.logging.log4j:log4-core:2.14.1.

Unpopular

Answer 28

Simply check the pom.xml file first and update accordingly if needed. And when you see the "[main] DEBUG org.apache.http.wire" multiple times on the screen, just let that happen completely and take time with doing nothing. Just look at your screen for a few... It will start running your suite soon.

Thanks

Abstractionism

Answer 29

For Spring (Boot) users:

Spring may load the logging config from logback-spring.xml in order to support Spring "extensions" (currently only profile-based logging levels).

I spent a couple hours experimenting before finding that logback-spring.xml will cause HttpClient logging not to pick up the level.

Renaming to logback.xml finally worked.

(I think this is a different cause worth it's own answer.)

Darendaresay

Answer 30

Create a logback.xml file with the following contents:

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

My project is set up with folder structure src->main->java and src->main->resources. Put this file in the resources folder.

Salad

Answer 31

Create a new file logback.xml into /src/main/resources and copy paste the following

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

<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
    <encoder>
        <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %msg%n</pattern>
    </encoder>
</appender>

    <root level="info">
        <appender-ref ref="STDOUT"/>
    </root>
</configuration>

Beautifully

Answer 32

There are many responses yet none appears to be complete. I had to cobble up answers and solutions from answers here and other locations, as well as my trial and errors. Finally, I am working with Log4j2.

First, create log4j2.xml in the resources directory. This directory is in the src/main/java. My logger is very simple:

1. write logs to console, everything above DEBUG level.
2. suppress DEBUG from very org.apache.http package.

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO">
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%p %m%n"/>
        </Console>
    </Appenders>

    <Loggers>
        <Logger name="org.apache.http" level="warn" additivity="false">
            <AppenderRef ref="Console"/>
        </Logger>
        <Root level="info">
            <AppenderRef ref="Console" />
        </Root>
    </Loggers>
</Configuration>

Second, set up your project pom.xml file. It is critical to include not only the dependencies to enable Log4j2 but also the bridge JARs. The bridge JARs will tell other dependencies to explicitly use Log4J2.

...
        <!-- Logging using Log4j2 -->
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>${log4j-version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>${log4j-version}</version>
        </dependency>
        <!-- Bridges to use Log4j2 -->
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-1.2-api</artifactId>
            <version>${log4j-version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-slf4j-impl</artifactId>
            <version>${log4j-version}</version>
        </dependency>
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-jcl</artifactId>
            <version>${log4j-version}</version>
        </dependency>
...

Finally, in your code you set up the logger object:

private final Logger log = LogManager.getLogger(YourClass.class);

and use it as follows:

log.info("Your helpful log message.");

Hope it helps.

Gyroplane

Answer 33

The best solution I found was to use the maven enforcer plugin in order to prevent commons-logging from being used altogether. Then I added the slf4j dependency for logging instead. So add the following to your pom.xml

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

and also add the maven-enforcer plugin

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

Mesoblast

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

OK but this won't actually remove the dependency; what more, you need to replace the dependency with something that will act like common-logging. So this may not work for many scenarios. Especially older Spring apps. Lastly, this is not really solving the issue, but rather some config setup, and this answer doesn't explain the context. – Designedly

Answer 34

Simply add these two dependencies in the pom file: I have tried and succeed after trying the discussion before.

<!--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 and default Info while Debug will not be present; You can use:

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

to define the information you want to log:like Final Result like this. Only the information I want to log will be present.

Slapjack

The question doesn't mention Spring. More, this question brings in the obsolete commons-logging which most often will create more issues than solve. – Designedly

Answer 35

I tried all above solutions to no avail. The one soution that came the closest for me was the one suggesting creating a logback.xml. That worked, however nothing got logged. After playing around with the logback.xml, this is what I ended up with

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

Now All levels below DEBUG gets logged correctly.

Clarsach

This works because the root level INFO is applied to all loggers. But that's the LogBack default anyway, AFAIK. So it's likely you have some other logging config file somewhere, maybe some dependency. – Designedly

Answer 36

With:

• Log2J 2 2.11.2
• HttpClient 4.5.7 (elasticsearch 7.0.0 rest client)
• Using properties file to configure

One can add:

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

With 'httpclient' in the above example being a logical name you choose.

(Tested on Java 11 OpenFX application.)

Rochette

One can add it where? What is s the documentation followed? – Designedly

Answer 37

In my case I use xml configuration, and I append this to the configuration file

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

Groundsel

XML configuration of what? Append to what config file? Based on what docs? – Designedly