On Sat, 2006-03-04 at 20:08 +0100, Roland Weber wrote: > Hello all, >
Hello Roland, Low level components such as http-core, http-nio, http-auth and, imo, http-async must throw exceptions and never log messages either directly to stdout or via a logging toolkit. We must not impose a specific logging toolkit on the users of these components. > 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. There are no plans to remove wire and context logging from HttpClient > I believe we'll need both > for the HTTP components, too. I disagree rather strongly > 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. No need for workarounds. It is absolutely trivial to add wire logging on top of http-core by injecting a thin wrapper around standard data receiver and data transmitter. > 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. There are other means to achieve the same net result, bytecode enhancers for instance. > 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 :-) Logging per ce does not solve any problem. I regularly spend quite a bit of my time analyzing huge log files when trying to help people troubleshoot their problems with HttpClient. I usually find 99% of the context log entries completely useless. Usually only HTTP headers are of any use. Moreover, 90% of problems are caused by cookie or authentication headers. A tiny fraction of the time I have spent these years on grepping through all those wire logs could have been spent on writing a tutorial on how to enhance HttpClient bytecode to log just specific type of information. > 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. Again, there are no plans to do anything about wire/context logging in HttpClient. However, all low level components sitting beneath it should communicate with the caller using standard java mechanisms such as return parameters and exceptions. It should solely a job of HttpClient to log certain type of exceptions (malformed cookies, authentication retries, etc) > 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 think we should eat our own dog food. Besides, there is a lot of activity going out around commons [logging] these days. There are indications many sound concepts originating from UGLI will get incorporated into commons [logging] > > 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. > Go for it Cheers, Oleg > Please let me know what you think. > > cheers, > Roland > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
