[jira] Commented: (HTTPCLIENT-609) Use TRACE logging instead of DEBUG for the absolute nitty-gritties

["Roland Weber (JIRA)" <ji...@apache.org>]

    [ http://issues.apache.org/jira/browse/HTTPCLIENT-609?page=comments#action_12453981 ] 
            
Roland Weber commented on HTTPCLIENT-609:
-----------------------------------------

Hello Endre,

you are answering most of your suggestions yourself. Let's start with the last one, the different logger roots. That issue is known as HTTPCLIENT-497. Unfortunately, we missed it for 3.0 as well as 3.1 and can't change it now in 3.x without breaking compatibility. That's a clear wontfix.

For the rest, we have only two developer log levels to choose from, and we must use them carefully. For example, the wire log which you mention uses DEBUG for the status/response and header lines and TRACE for the message entities. That's because we want to be able to get a wire log of the headers without potentially dumping megabytes of binary data we're not interested in. Other parts of HttpClient may face similar tradeoffs.
The developer log levels are there so we, the developers, can get information we require to help users when debugging problems in various places throughout the HttpClient code. I think it is not undue that we are allowed to use two different developer log levels everywhere in order to reduce the logging noise where appropriate. If you decide to switch on DEBUG traces for _all_ of HttpClient, it's only fair that you suffer the consequences. I don't think we should have to restrain ourselves to all-or-nothing logging for DefaultHttpParams or HttpMethodBase or any other part of HttpClient because you're only interested in some of the log messages and don't want to bother with configuring your logging framework accordingly.

Saying that, if you feel there are parts of the code where we _locally_ used the two developer log levels inappropriately, or where log message phrasing could be improved, we'll happily review, discuss, and accept patches :-) I'm afraid we don't have the personpower available to perform a review of log levels for the old code base just for the fun of it. HttpClient 3.x is on life support because we are focusing our efforts on HttpComponents 4.0.

cheers,
  Roland


> Use TRACE logging instead of DEBUG for the absolute nitty-gritties
> ------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-609
>                 URL: http://issues.apache.org/jira/browse/HTTPCLIENT-609
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>    Affects Versions: 3.1 Beta 1
>         Environment: n/a
>            Reporter: Endre Stølsvik
>
> [This is basically a copy of the Spring improvement request SPR-2873: http://opensource.atlassian.com/projects/spring/browse/SPR-2873 )
> Given a developer situation: Much of the DEBUG information in the log of HttpClient is very un-interesting as long as it works. Some of these lines are however of much bigger importance than others (thus turning off DEBUG globally for HttpClient isn't good either).
> TRACE and DEBUG are the two developer-centric logging levels of log4j and commons logging (the rest are "production levels"). Since log4j-1.2.12, TRACE have existed. Clogging have always had trace, but before release 1.1 mapped Log.trace to log4j's DEBUG, but 1.1 (released May 9. 2006) now maps to log4j's TRACE.
> I think that HttpClient's logging would benefit a lot by using TRACE level extensively, in that developers could turn all of httpclient's logging down to DEBUG, but still see "major developer events" like connections being opened, the request being sent, and e.g. the response's status line, size of headers and body, keep-alive vs. closing of connection.
> Candidates for TRACE level include:
>   * httpclient.wire.*
>   * org.apache.commons.httpclient.params.DefaultHttpParams
>   * org.apache.commons.httpclient.HttpMethodBase
>   * .. and probably a bunch of others that doesn't bring the developer in the standard "good flow mode" any highly interesting information. 
> Please note that I do NOT view these lines as worthless. It is however in _normal_ developer circumstances not valuable information, and it would ease development if it was possible to turn these ultra-verbose loglines off easily. When things just aren't working out, and your exciting REST-based query doesn't work out, or your charset encodings just doesn't give what you're expecting, you'd turn on TRACE to really get down to the hard core. You'd find the problem, fix it, and set it to DEBUG again.
> In addition, the lines that were left on the DEBUG level should obviously be as informative as possible, and thus maybe somewhat more verbose than now, trying to "aggregate" some pieces of information that now are output over several DEBUG lines..
> I do realize that I could achive a lot of this with a rather extensive log configuration, that also had to include raw text filters, but I do believe that this affects more developers than me!
> PS: it wouldn't hurt either if all of httpclient's log-lines came from a common root, e.g. "HttpClient", or "org.apache.commons.httpclient", instead of having several roots. This would however be a somewhat "backward incompatible" change, since it now has (at least?) two roots.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

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