[ http://issues.apache.org/jira/browse/HTTPCLIENT-609?page=comments#action_12454563 ] Endre Stølsvik commented on HTTPCLIENT-609: -------------------------------------------
Yes it clarifyes things a good bit. I guess I didn't realize the extent to which 3.x is "abandoned". Looking forward to a new'n'fresh 4.0, then! :) (with new'n'fresh bugs?! :) ) I guess simply coming up with an "exact" set of log-lines that could do with trace doesn't cut it? It has to be actual patches? (Setting up a new project just takes some time..) If you'd just set the one log-line that dump the wire (Onto logger "httpclient.wire.content") to do log.trace(..) instead of log.debug(..) next time you're around that code, that would help a lot, I believe. (Actually, the number of bytes read in one chunck could be nice to have output on debug, in addition to all the actual wire content ouput on trace - this would give a nice interleaving effect with the processing of the body of the response, so that _my_ debug or trace lines was interleaved with the actual TCP connection "chunk" fetching..). I'll try to come up with a patch for some more. NB/PS: Once again, I actually think that _extensive_ logging og httpclient rocks. Having the actual wire-content available in such a nice output is really nice. It's just "a bit" on the verbose side when things actually are working! Thanks, Endre. > 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 > Priority: Minor > Fix For: 4.0 Alpha 1 > > > [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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
