hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: The Logging Non-Problem
Date Mon, 06 Mar 2006 18:56:30 GMT
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/%3c9FF54B46-998A-11D8-8D93-00306557E112@u.washington.edu%3e
[...] 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: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message