lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: logging through log4j (or better yet, SLF4J)
Date Fri, 02 May 2008 00:38:45 GMT

: Being able to override the default implementation fortunately allows to
: implement the must-have feature you describe as the "ClassLoader specific
: LogManagerManager", I agree; however, I think it should have been in the
: default implementation. I view this as a major regression from the previous
: de-facto standard (aka log4j).

take this to the logical conclusion: if JUL's LogManager did implicitly 
allow configuration per ClassLoader, then in the case of Something like 
Solr, where each core constructs a ClassLoader for loading plugins, you 
could wind up with a plugin jar mucking up the logging (for it and other 
plugins loaded by teh same class loader) and ignoring the LogManager you 
choose for Solr.

Security and configuration and flexibility have to start at the root of 
the tree and be passed down. the "root application" (servlet 
container in our case) needs to say "i'm going to use a LogManager that 
allows code i load at runtime to pick it's own LogManager".  The converse 
is also true, a servlet container needs to be able to say "i'm not going 
to allow webapps to log willynilly, all messages must get funneled through 
me via a central config." ... it just so happens that the  later is the 

: There are organisations where IT responsability ends at application
: security/start/stop (the more apps/servers running, the more likely &
: common); people in charge of the application content & usage do monitor
: their logs. In this case, the unified logging pipeline (ala Websphere/JUL
: for instance) is in fact inconvenient (fortunately, WAS also support
: commons/log4j/...).
: IT logs are expected to only contain container/services logs and
: applications are highly encouraged (aka expected) to deal with their logging
: needs themselves.

Then the IT people setting this expectation should be providing you the 
basic tool you need to satisfy it: a servlet container using a LogManager 
that will delegate to a LogManager (or LogManager configuration) per 


View raw message