Hi all, my preference is clearly to stick with commons-logging. I've checked SLF4J before I closed HTTPCLIENT-416, and didn't like it. Some of that was based on a misinterpretation, but other things persist. They defined a new formatting style which is positional and not compatible with the indexed java.text, though that won't be an issue in the HttpComponents context. The absence of a trace level has already been mentioned by Anders. Using log and trace levels would be a real improvement over HttpClient 3.x.
My view on Standard Java Logging is worse, based on some practical experience in a long-running project at work. The design deficiency of passing bundle names without classloader wouldn't hurt us since we don't have to NLS-enable messages. But since it is a standard API, there are environments where standard java logging is kind of hijacked by the environment and taken out of application control. (Yes, WebSphere) With commons-logging and it's classloader based mechanism, the control over which logging API is actually used under the cover is as close to the application as possible. I'm not sure how the SLF4J technique works in practice, so my argument against that is the missing trace level. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
