logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Schilli <log4p...@perlmeister.com>
Subject Re: Log4j configuration in class libraries
Date Mon, 14 Jul 2003 20:44:23 GMT
On Fri, 11 Jul 2003, Jacob Kjome wrote:

> I'm in almost total agreement with what you've just said. Logging
> configuration should be set by the application, not its libraries.
> Libraries shouldn't be adding a log4j.properties or log4j.xml file to
> their classpath, thus triggering automatic log4j configuration.
> However, the application always has the opportunity to explicitly
> configure things first. If you do this, automatic configuration using
> the libraries specific configuration file will be avoided, in which
> case you shouldn't have a problem with a library overriding your own
> configuration. Additionally, you could take advantage of the fact
> that, say, in webapps, resources from WEB-INF/classes are loaded
> preferentially to resources from jars in WEB-INF/lib. In this case,
> your own app's automatic configuration will run first and, just as in
> the latter case, avoid additonal automatic configuration via another
> library's configuration file. On the other hand, if a library is
> explicitly doing configuration in some static block or something, that
> is just totally inappropriate and should be very discouraged.
> Hope that helps.

Thanks, that helped. In Log::Log4perl, we've got a static init() method
which will load a specified file as its configuration. If a library does
that, it'll overload the applications init() call (if it has been called

Guess, the only way to avoid any confusion is to advise people not to do that
and document their Log4j requirements with their libraries.

I was wondering if there's any plans in Log4j to deal with multiple
configurations which interfere with each other, e.g. by having separate
namespaces for appender names, rules on what happens if different parts
of the system define conflicting appender thresholds etc.

Agains, thanks for your help!

-- Mike

Mike Schilli

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

View raw message