Although I didn't dig out my problem completely, this sure looks a lot like what I had troubles with: log4j was initialized, but not with the log4j.properties in web-inf/classes. But the behaviour did vary, sometimes it worked ok (could have to do with library I moved in and out).

The solution of having an autoload servlet force-initializing log4j, took all my troubles away though.

Tom



David Tonhofer, m-plify S.A. wrote:

Hi,

This has probably cropped up before? Correct me if I'm wrong (I'm
always happy to get an earful about nonexisting problems) but...:

The gist:

 "In some (most?) cases you cannot use a 'log4j.properties'
  file placed in your web application's WEB-INF/classes
  directory"

...this goes counter to the Log4J's documentation, which says:

 "The default log4j initialization is particularly useful in web-server
 environments. Under Tomcat 3.x and 4.x, you should place the
 log4j.properties under the WEB-INF/classes directory of your
 web-applications. Log4j will find the properties file and initialize
 itself. This is easy to do and it works."

So why doesn't it work?

-> When Tomcat starts up and one of its own classes and/or
  some classes in its "common" or "shared" classloaders use
  log4j (possibly indirectly through commons-logging), then:

-> Tomcat will initialize log4j logging through the relevant
  classloaders (named "StandardClassloader"). Unfortunately,
  whatever is in a Webapp is completely invisible to such a
  classloader. Thus, the file log4.properties in the
  WEB-INF/classes directory is irrelevant at this point.

-> At the first request of a Servlet, the WebappClassloader
  could in principle start log4j initialization using the
  log4j.properties file because it is visible to it.
  Unfortunately, at that moment, the org.apache.log4j.LogManager
  class has already been loaded, its static initializer executed.
  And thus, initialization will not be done again.

This can be easily seen by switching LogLog logging on and
by adding some test code to a servlet.

On Tomcat startup, we get the details of the classloaders. They
are all called 'StandardClassLoader' and the last message is:

log4j: Trying to find [log4j.properties] using ClassLoader.getSystemResource().
log4j: Could not find resource: [null].
log4j:WARN No appenders could be found for logger (org.apache.commons.digester.Digester).
log4j:WARN Please initialize the log4j system properly.
Starting service Tomcat-Standalone
Apache Tomcat/4.1.24


As you can see, "org.apache.commons.digester.Digester" caused
premature initialization.

The servlet, containing this code (essentially the same as the one called
by LogManager):

Method method = Thread.class.getMethod("getContextClassLoader", null);
ClassLoader ccl = (ClassLoader) method.invoke(Thread.currentThread(), null);
URL url = ccl.getResource("log4j.properties");
LogLog.debug(url.toString() + " using " + ccl + ".");


will give this output:

log4j: setFile called: velocity.log, true
log4j: setFile ended
log4j: file:/C:/eclipse/workspace/log4jtest/WEB-INF/classes/log4j.properties using WebappClassLoader
available:
delegate: false
repositories:
/WEB-INF/classes/
required:
----------> Parent Classloader:
StandardClassLoader
available:
delegate: true
.....


I don't see that this problem is in any way solvable. Also, should it be?
Wouldn't log-configuration from the webapp give the webapp too much power
over Tomcat? It probably would.

The solution is of course to move the 'log4j.properties' file higher: ask
the friendly BOFH to move it into the 'common-classes' for example. But
that's another story.

Best regards,

    -- David Tonhofer
    M-PLIFY S.A.


























--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to