You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Matt Raible <ma...@raibledesigns.com> on 2002/12/06 19:33:59 UTC

Best Practices for Logging?

I'm wondering what is considered the best practice for logging using 
commons-logging in a Struts app.  My current approach is to have a Base 
class in every package that has the following:

protected Log log =
         LogFactory.getLog("my.package.name");

But I've noticed that some of the Struts examples have an instance of 
this in every class.  Is this recommended, so that logging can be done 
on a class level, as well as a package level?  Any thoughts/opinions 
are appreciated.

Thanks,

Matt

Re: Best Practices for Logging?

Posted by Michael Rimov <ri...@centercomp.com>.
At 11:33 AM 12/6/2002 -0700, you wrote:
>I'm wondering what is considered the best practice for logging using 
>commons-logging in a Struts app.  My current approach is to have a Base 
>class in every package that has the following:
>
>protected Log log =
>         LogFactory.getLog("my.package.name");
>
>But I've noticed that some of the Struts examples have an instance of this 
>in every class.  Is this recommended, so that logging can be done on a 
>class level, as well as a package level?  Any thoughts/opinions are 
>appreciated.

Matt,

I use log4j for Expresso, but the concepts are similar to commons 
logging.  I've found that for my own use, the full class name is the 
absolute best for logging.  It allows me to turn on debug logging for 
entire packages or single classes if need be.  [There are some classes, 
that I start more than one log!]

Doing profiling on the app, I haven't found any serious memory problems 
with doing things this way.

So I'd seriously consider a different log per class.... but the nice thing 
is, that if you find it doesn't work for you, you can always change things 
back to per package with one line mod per class.  :)

HTH!
                                                 -Mike



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>