hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HTTPCLIENT-1054) HTTPClient per default relentlessly spams to stderr
Date Mon, 07 Feb 2011 13:34:30 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991377#comment-12991377
] 

Oleg Kalnichevski commented on HTTPCLIENT-1054:
-----------------------------------------------

Which version of HttpClient is this issue for? 

Commons HttpClient 3.1 does indeed have a tendency of abusing INFO priority logs for logging
often irrelevant details. This problem has long been solved in the 4.x series. 

Oleg

> HTTPClient per default relentlessly spams to stderr
> ---------------------------------------------------
>
>                 Key: HTTPCLIENT-1054
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1054
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: HttpClient
>         Environment: all
>            Reporter: Wulf Wechsung
>            Priority: Minor
>              Labels: default, logging, soc
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> HTTPClient relentlessly spams to stderr when including it into a project via maven. This
is not a decent default behaviour for a libary. Libaries should, per default, communicate
their internal state solely and adequatly via their API and let it be up to the application
to react to that state (logging it is one such reaction). From some replies to tickets in
the same vain I can see that this is perhaps a sensitive topic as some see logging to be a
core concern of HTTPClient. I do agree it's helpful as a debugging tool but as such it needs
to be opt-in. As a standard error output, the logging of HTTPClient is absolutely useless
because it does not and can not describe what the application is trying to do.
> Why this improvement when there is a way to disable HTTClient logging (in fact, there
seem to be many ways ... always a bad sign ..)?
> Do a google search for: httpclient "console spam"
> 204 hit for this harsh phrasing alone. Search this phrase for any other libary you like
to use and compare the number of hits. Ask youself, how often have you seen the java standard
libary write to stdout or stderr?
> Personally, I tried to disable it via JDK14 getLogger("org.apache").setLevel(Level.OFF)
 which wouldn't work and now am using a solution I found on Stackoverflow which is:
> System.setProperty("org.apache.commons.logging.Log", "org.apache.commons.logging.impl.NoOpLog");
}
> The problem I have is that I include this lib and suddently my console is useless because
httpclient is all over it (writing a system monitor ...). I have to search google to find
a solution (http://hc.apache.org/httpcomponents-client-ga/logging.html does not tell you how
to turn logging off ...) and the logical one "turn of the JDK logger" does not work right
away.
> It's really a matter of following the principal of least suprise (a libary is not expected
to write to the console which is the observable default behaviour of HTTPClient) and the principal
of separation of concerns (logging is a concern for applications and not for libaries).
> Following at least one of these would substantially increase the joy of working with
the HTTPClient libary.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message