hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject The Logging Problem
Date Sat, 04 Mar 2006 19:08:44 GMT
Hello all,

I am in doubt what to do about logging. It is one of our project goals
to minimize the dependencies on external libraries, including logging.
http-core currently does that in a very straight-forward way: it does
not log at all. Only the HttpService has some logging statements, which
call methods that do nothing and have to be overridden in a derived
class in order to generate output.
I don't think this approach will last. Wire logs are our primary means
to help people with strange server behavior, or to detect faults in the
requests built by their applications. The non-wire logs are important
to track problems in the HttpClient behavior. I believe we'll need both
for the HTTP components, too. I sure don't want to waste my time with
guessing what the components do in absence of log files.
Within http-core, we can implement some workarounds. For example, we
can use different implementations of connections or data reader/writer
to get a wire log, and different implementations of HttpMessage and
derived interfaces to log information about header updates. But that
is second-rate logging, because the log statements are not where the
action takes place. It also requires users to change their application
code in order to generate log output. Or to use and reconfigure a
Spring style mechanism. We can't tell them anymore to just add a few
properties here or there to enable logging.

I understand the desire to not have to configure commons-logging. But
as a developer, I do have a strong desire to get an informative log if
people expect me to help them. And if the decision is between my time
for analyzing their problems, or their time for installing a logging
component, you can guess what I prefer :-)
Even if we can live without logging in http-core, I expect most people
to use some other components as well, like http-auth or http-client.
The desire to not install a logging component will hardly be addressed
if frequently used non-core components do require one. Are we going to
have a discussion for each component whether it is complex enough to
require log statements, or is used so frequently that it should not
depend on logging?

The best idea I've had so far to address both concerns - and I'm not
claiming it is a good idea - is to compile two versions of each component.
The default one with logging statements, and an alternative nolog version
where all log statements and other dependencies on logging (imports)
have been removed from the source.
Technically, that requires preprocessing to generate the nolog version.
I have found this blog entry about using Ant filters for preprocessing:
http://weblogs.java.net/blog/schaefa/archive/2005/01/how_to_do_condi_1.html
The charm of this idea is that the source code remains valid Java source
and can always be compiled without preprocessing. Even the line numbers
of the preprocessed source will match those of the original source, which
is important for interpreting stack traces.

A second logging question is which logging framework we should use. There
is still a decision pending about whether to switch from commons-logging
to Log4j UGLI: http://issues.apache.org/bugzilla/show_bug.cgi?id=32937
I implicitly assume that we want to use the same logging framework for
all HTTP components that require logging, so this should be discussed
before I put logging into http-async. Currently, I am not convinced of
the advantages of UGLI over commons-logging, but I haven't yet studied
UGLI in detail.


I intend to have another programming stint on http-async next weekend and
a few days of the week after. I hope for feedback on the logging questions
until then. If we come to a common understanding, and if time permits,
I would like to make http-async the pilot for all our components that are
going to use logging. But considering the effort it would take, I don't
want to rush ahead and implement something that will not be accepted as
the basis for other HTTP components.

Please let me know what you think.

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