Re: [httpclient] logging and testing changes

[Remy Maucherat]

Title: [httpclient] logging and testing changes

(My apologies if this comes through with an HTML attachment.  Our admin recently upgraded our exchange server and seems to be having trouble getting the "stop-sending-the-annoying-attachment" patch/config set up again.) (And of course, whever my stupid OE sees an HTML attachement, it goes into HTML mode)   I was about to vote -1, actually.   Basically, at the very least, I would have liked to release 1.0 before. Besides that change would force an application to use log4j. Something like an HTTP client library should be as lightweight and as unobtrusive as possible IMO. I also don't like log4j a lot anymore (but that's my personal opinion, so you can ignore that). Fair warning: I'd like to convert the System.out/System.err logging currently used in httpclient over to using log4j, for the following reasons: * The current logging configuration is cumbersome--it requires a code change and recompilation to turn logging on and off.  Several times over the past few days I've wanted to quickly turn logging on or off in a production installation of httpclient, and have had to replace the JAR outright--which may be changing things other than what I wanted to change. There is a setDebug call on HTTPClient. * Many of the projects using this component probably already use log4j for other logging, so making it all work the same way would be helpful. Not true. Slide doesn't use log4j. As many projects probably have, it has a logger interface, and an implementation of the logger interface which can use log4j (by using it is 100% optional). Actually, what I would do eventually in the client lib is get rid of all the logging calls, and replace them by using hooks like the ConnectionInterceptor. That way the application gets all the significant events about what's going on, and can decide what (or what not) to log. This is much more flexible, and allows for embedding the client cleanly. * Previously on this list we seem to have come to a consensus (or at least as close to a consensus as this list ever comes to) that log4j should be the conventional logging mechanism There was no vote or anything like that. * Given the charter of this project, it seems appropriate that we use bits of other jakarta/apache projects where relevant. Remy