Michael Becke wrote: > So how does this sound? > > - If/when we do end up using a logging package we will use Commons Logging > - Commons Logging will be a dependency for HttpClient and most likely > http-async and http-conn > - Wire logging will be accomplished via a custom sender/receiver > wrapper. This wrapper will be included as a part of HttpClient, and > can always be used independently from SVN.
That sounds good so far. > - Trace logging is of no real help and will not be included in any of > the packages. People who really want it could always add via aspects, > etc. Well, maybe I'm a little behind on those modern techniques. The last thing I heard was that aspects can add things at the beginning or end of methods, but not within. In other words, aspects would give me entry/exit traces. Those are the traces I hardly care about. They mostly are textual noise that drowns the important information in the log. What I want to use, and what I am using on an almost daily basis at work, are traces within a method that tell me whether the code executes the "if" or the "else" branch, or which values some interesting variables have, and so on. In other words, trace logging. Apart from manually inserted System.out.println statements, trace logging is my primary means of debugging my code. It is the only help on which I can rely once the code is running as part of somebody else's application. And I find it to be of immeasurable and very real help. I've noticed before that you do not really make use of such logging: http://mail-archives.apache.org/mod_mbox/jakarta-commons-httpclient-dev/200404.mbox/[EMAIL PROTECTED] [...] We generally don't use the different loggers to filter logging[...] But my development style very much depends on it. Of course I could code locally with trace logging and remove the log statements for the patches. But I have no intention of wasting my time by chasing user's multithreading problems in the absence of log output from "my" background threads. And I expect multithreading problems to be the major part of problems with http-async (assuming that anyone is going to use it in the first place :-) Neither do I trust sophisticated, nebulous applications to instrument my code with really useful trace logging, because only I (or other humans that dig into the source code) know where the few crucial parts of the code are, and what information needs to be logged in order to trace their behavior with little noise. That's why I suggested to compile two versions of the component(s) in the first place: one without logging for the people who don't want the dependency, and one with logging for the people who want me to help them. > - Our goal is to do without logging for the core APIs. This will > continue to be our plan until we run into a situation that changes our > mind. I have no problem with that. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
