You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Darren Hartford <dh...@ghsinc.com> on 2005/11/09 16:06:57 UTC

Best practice - container-level vs application-lvl logging?

Hey all,
Does anyone have some articles, pointers, or even books that talk about
best practices in regard to seperation (or integration) of
container-level logging (Tomcat, Jboss, etc) versus application-level
logging?

To be more descriptive, most containers already have existing loggers in
place, and the question is what the best practice is for applications
that use these containers from the logging standpoint -- have the
application control it's own logging, integrate applications logging
with the containers loggging, etc.

Thanks, any advise would be welcome!

-D

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


Re: Best practice - container-level vs application-lvl logging?

Posted by Jacob Kjome <ho...@visi.com>.
Quoting Darren Hartford <dh...@ghsinc.com>:

> Hey all,
> Does anyone have some articles, pointers, or even books that talk about
> best practices in regard to seperation (or integration) of
> container-level logging (Tomcat, Jboss, etc) versus application-level
> logging?
>

Try searching this list and the web about using the Log4j RepositorySelector. 
Besides that, if you use child-first classloader for webapps, you can separate
your app logging from the container by including log4j.jar in WEB-INF/lib.  In
this case, always put log4j.xml in WEB-INF/classes, even if it is a dummy
config file where you might be performing manual configuration for whatever
reason.  Not putting log4j.xml in WEB-INF/classes risks auto-configuration at
app startup against a Log4j config file found in a higher classloader if it
isn't found in the child first.  At times, this can cause unexpected behavior.


> To be more descriptive, most containers already have existing loggers in
> place, and the question is what the best practice is for applications
> that use these containers from the logging standpoint -- have the
> application control it's own logging, integrate applications logging
> with the containers loggging, etc.
>

Repository selectors allow you to use a global version of Log4j in the server's
classpath while allowing for individual apps configuring themselves in distinct
logger repositories from the default on the server is using.  Of course, if you
wanted more than one app to log in the same logger repository, then you can
also do that to.  For instance, with the ContextJNDISelector (in Log4j-1.3 and
a Log4j-1.2-compatible version in the sandbox), you can define the name of the
JDNI key per-app that you want to log to.  So, if multiple apps use the same
key, then they log to the same logger repository.

Anyway, for more, do a simple search.  You should find lots of results.

> Thanks, any advise would be welcome!
>
> -D


Jake

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