> From: Morgan Delagrange [mailto:[EMAIL PROTECTED]] > > Yes, the defining advantage to the commons-logging API that I see is that > it > allows users to adopt a single logging implementation, which confers real
What needs to be appended to that statement is "...if everyone codes to the commons-logging API". The exact same statement can be reconstructed using "Log4J API" and it is equally true. If everyone uses commons-logging, then only one logger must be configured. If everyone uses Log4J, then only one logger must be configured. If third-party software is using different loggers, then you have to configure multiple loggers no matter what API your code uses. It seems to me that the commons-logging API just adds Yet Another Logging API... especially when someone gets the bright idea to make a "native" implementation of the API for performance reasons. At least with Turbine, Struts, (Maverick :-), etc, there are some fundamentally different approaches to the problem of how to publish a web application. Logging doesn't seem that complicated. The massive duplication of this basic feature in the Jakarta codebase is silly, and trying to build an abstraction layer on top of it seems even sillier. Jeff Schnitzer [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
