[ http://issues.apache.org/jira/browse/HTTPCLIENT-609?page=comments#action_12454408 ] Roland Weber commented on HTTPCLIENT-609: -----------------------------------------
Hello Endre, yes, I read your entire description at least twice before answering. It does not mention anywhere that TRACE level is not used at all. If that is indeed the case (I haven't checked) I agree that this could be improved by making use of both log levels. Remember my invitation to provide patches? Your examples include wire logging, which is exactly the place where I know we've been using both levels. The other specific examples are not DEBUG statements that should be downgraded, but whole classes - which I interpreted as a request to downgrade all DEBUG statements in those classes. Just moving all log/trace statements of a whole class from DEBUG to TRACE is imho not an improvement. If all output is currently at DEBUG level, it's not a deterioration either, I'll grant you that. It's just work that somebody has to do. What you actually suggest is that we review all DEBUG level log statements and decide which of them should be downgraded. That is a _lot_ of work, and we already have more work on our list than can be achieved in a reasonable amount of time by those active developers we have. Remember my invitation to provide patches? Reviewing patches is work as well, but it's something I am willing to spend time on. I have adopted the terminology which is commonly used on our mailing lists and in our wiki. Developers are folks working on our code base, users are folks using our code base. We put a lot of effort into keeping our users happy and satisfied. Logging is one of the tools we require to do that. But it's not a core functionality that is broken and needs fixing. It could be improved all right. The question is: who's going to spend the time for doing that? Since you're probably not familiar with our staffing situation, here is a short overview. We have one and a half active developers. Since about a year ago, we are putting our efforts into a _complete_ overhaul of the API and code base, to become HttpComponents 4.0. We've made some progress, but we're still months if not years away from even a beta of HttpClient 4.0. There is a reason why we overhaul the API completely: the 3.x API is broken by design. We've put in as much functionality as can reasonably be put in (maybe even more), but we can't continue along that road. The code needs a complete rework, and that's what we're doing. Which means that 3.x is a legacy code base into which we'll put as much effort as needed, but as little effort as possible. We are all quite willing to keep both camps happy. To keep "our" camp happy, all you have to do is find someone who's going to submit patches. Both Oleg and I, and probably also some of the less active committers, will gladly spend our time on reviewing such patches so they can be integrated into the code base. And we'll do that out of respect for the effort of whoever it is that comes up with the patches. What you can not expect Oleg or me to do is to spend our limited time on cosmetic improvements of the legacy code base, while the todo list for the new code base is growing from months to years. If something is broken in 3.x, we'll fix it. If somebody submits patches for improvements, we'll review them to get them in as quickly as possible. But we're not going to do code reviews for mere improvements. I hope this clarifies things a bit. My response was not meant to imply your suggestions are unreasonable. I rather wanted to point out that they are cosmetic in nature, have a minimal priority on our list, and there's nobody at hand to do the work. If anyone steps forward to help maintain the legacy code base, we'll gladly support such effort. 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 > 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]
