I have been using log4j with Tomcat (and Struts), I've beeen putting log4j.jar in
the WEB_INF/lib and log4j.properties in WEB-INF/classes directories, and haven't
had any problems.
Shunhui
-----Original Message-----
From: William Jaynes [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 9:29 AM
To: LOG4J Users Mailing List
Subject: Re: log4j.properties file location bug?
I find that if I (1) write a little test program and run it from a
command line, and (2) use the log4j static initializer, and (3) the
log4j.jar file is in the jre/lib/ext directory, then the
log4j.properties file is found no matter where it is as long as it is
in a directory that is on the classpath. If the log4j.jar file is not in
jre/lib/ext then I find that as long as it is on the classpath and
log4j.properties is in a directory on the classpath, then the static
initializer finds log4j.properties. I do not find, as you do, that they
both need to be in the same directory.
However, my real applications are web applications running with Tomcat
or Resin. This means that I'm dealing with at least 4 different
classloaders, and this leads to problems (which I recently talked about
in the "log4j static initializer" thread). I trace the problems to the
static initializer in the Category class, where the "log4j.properties"
file is searched for using the following call: "url =
Loader.getResource(resource, Object.class);" This means that the
bootstrap classloader, the classloader for the Object class, is used to
find log4j.properties. And that means the the mechanism used to find the
log4j.jar file is completely separate from the mechanism the static
initializer uses to find the lo4j.properties file.
For me, in a web app, this means that I can put log4j.jar in my
WEB-INF/lib and log4j.properties in my WEB-INF/classes, but the static
initializer won't find the properties file because the bootstrap
classloader isn't the classloader that knows about my web app.
My suggestion is that the Loader call should be "url =
Loader.getResource(resource, Category.class);". This would cause the
static initializer to use the same classloader to find the
log4j.properties file as was used to load the Category class. If I make
this change in the source of Category.java, then I can put log4j.jar in
WEB-INF/lib and log4j.properties in WEB-INF/classes, and the static
initialzer works for each of my web apps.
I must confess that I'm still new to all this classloader stuff and am
not totally confident that I understand it completely. For example,
using my changed version of log4j.jar I would expect that I could take
the jar and properties files out of my web apps and put them in
/tomcat/lib and /tomcat/classes, respectively, and then all my web apps
would use the same log4j.properties file, and the static initialize
would work for them also. But I find that this doesn't actually work and
I don't see why not.
(There are a number of papers talking about classloaders in detail at
http://www.javageeks.com/Papers/ .)
Regards, Will
----- Original Message -----
From: "Hansen, Richard" <[EMAIL PROTECTED]>
To: "LOG4J Users (E-mail)" <[EMAIL PROTECTED]>
Sent: Friday, May 04, 2001 11:43 AM
Subject: log4j.properties file location bug?
> I don't know if this is a exactly bug. But is an issue and should at
least
> be added to the FAQ I think. To get log4j to automatically load a
properties
> file I need to explicitly add the log4j jars to the classpath. Next, I
must
> put the properties file in the same directory as the log4j jar files.
Last,
> I need to add the directory with the jars and property file into the
> classpath. Someone please correct me if I am wrong, but that is the
only way
> I could seem to get working.
>
> This means that you cannot put log4j jars in the "jre/lib/ext"
directory for
> auto loading by the JVM. Even if you add the "jre/lib/ext" directory
to the
> classpath and put the property file there log4j does not find it. Does
the
> XML configuration work the same way?
>
> Rick Hansen
>
>
> ---------------------------------------------------------------------
> 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]
