logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: Log4j in tomcat common/lib and in WEB-INF/lib
Date Wed, 27 Jul 2005 07:11:44 GMT
On Tue, 2005-07-26 at 11:35 -0700, Elias Ross wrote:
> On Tue, 2005-07-26 at 09:49 -0700, Mark Palmer wrote:
> > My code and needs to be common/lib (i.e. don't want to
> > modify the web application war file in any way)
> > 
> > This means log4j needs to be in common/lib as well.
> This is more of a user question (and a FAQ really), but here's an idea
> I'd like to share that's somewhat related.
> You can add a custom appender from a classloader that log4j doesn't see
> upon start-up by first loading the base "generic" configuration, and
> when your model boots, add the appender to the category/logger tree,
> e.g.
> Logger.getRootLogger().addAppender(new MyWarFileAppender())
> But this gets hard to configure.  So, it would be nice to have a model
> that allows you to "merge" a log4j.xml file with an existing
> configuration.  So, you could have:
> log4j.xml (base)
> log4j-custom.xml (gets loaded by a servlet)
> And declared categories/appenders etc. would be overlaid onto an
> existing configuration rather than replacing the existing configuration
> outright.

Log4j has the ability to be configured with custom repository
(hierarchy) selectors. If a Contextual Repository Selector is used then
log4j will set up a separate logging enviroment for each distinct Thread
Context Class Loader (TCCL) - and each webapp has its own TCCL. The
Contextual Repository Selector also looks for the initial log4j
configuration files in the TCCL path so that log4j.xml or
log4j.properties in the webapp's path will be used instead of the one in
the container's path.

The container does need to explicitly set up log4j to use such a
selector however.

See http://www.qos.ch/logging/sc.jsp

Note that I don't personally agree with all of Ceki's arguments in the
above link.

> And maybe people wouldn't feel as compelled to bundle log4j.jar into
> every .war deployment...

I've never understood this view of the world. A standard servlet or j2ee
container has a set of libraries that it is *required* to provide to
components. But log4j is *not* part of that set. Therefore components
*should* bundle log4j if they want to use it.

To me, it's ugly and evil for jars to be added to shared classpaths in a
container. The container is the container, and the component is the
component, and bits of the component do not belong in the container.



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

View raw message