[OT] Log4J raw vs. commons-logging/Log4J (was Re: Log4j with Struts)

[Kirk Wylie <kw...@m7.com>]

Joe Germuska wrote:
> At the risk of quibbling, I would dispute this as a general rule; 
> commons-logging is great for library packages which may be used in a 
> variety of contexts, but unless you're writing a Struts application for 
> general distribution and re-use, there's less justification for using 
> commons-logging universally.
> 
> There's nothing wrong with using commons-logging in applications and 
> other more finished products, but commons-logging is a greatly 
> simplified API (for good reason) and in an application, you may find it 
> worthwhile to commit to a more sophisticated logging tool (like Log4J) 
> in order to have more powerful logging features.

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?

Kirk Wylie
M7 Corporation


---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: [OT] Log4J raw vs. commons-logging/Log4J (was Re: Log4j with Struts)

[Joe Germuska <jo...@germuska.com>]

> 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
Joe@Germuska.com
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