Are you talking about the code-level interface (i.e. Log versus Logger) or in terms of the configuration? Because in our applications, we've taken the commons-logging approach, though we initialize the commons-logging package with a complex Log4J configuration, so that we have in essence the best of both worlds: we can use the behind-the-scenes power of Log4j, with the ability to swap out logging implementations that commons-logging gives us.
I've not seen much in the log-level API that's substantially different. What sorts of power are you talking about?
Specifically, in a recent application we chose to use Log4J directly rather than Commons Logging because we wanted to use Log4J's
"nested diagnostic context," in which you can basically store thread-local values (like current user) and have them available for all logging messages.
http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/NDC.html http://jakarta.apache.org/log4j/docs/FAQ.html#NDC
Certainly if the commons logging API is adequate, you're probably better off using it by default, just like you're better off writing your code to use JAXP instead of a specific XML parser, if you can get away with it.
The point being that the choice to commit to one api over an abstraction layer is much less important when you're writing a self-contained application than when you're writing libraries.
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association
smime.p7s
Description: S/MIME cryptographic signature
