I don't feel competent to comment on your classpath explanation, but I
do have the following empirical information.
Using log4j-1.1.1 with Tomcat 3.2.1, putting log4j.jar into WEB-INF/lib
and log4j.properties into WEB-INF/classes, the static initializer does
not find log4j.properties. Changing DEFAULT_CONFIGURATION_FILE to
"/log4j.properties" does not make any difference. Move
log4j.properties out to /tomcat/classes, which is on the tomcat
classpath, and the static initializer finds it. This I would expect.
Move log4j.jar out to /tomcat/lib, and again log4j.properties is found.
Move log4j.properties back to WEB-INF/classes and it isn't found.
All of the above behaviour is expected (by me) except for the first.
Packaging log4j.jar and log4j.properties into a web application should
result in the static initializer finding the properties file in the web
application. In the current release, this does not happen.
I trace this anomaly to the following line in Category.java
url = Loader.getResource(resource, Object.class);
I believe that "Category.class" rather than "Object.class" should be
used. ClassLoaders are organized into a hierarchy, and the one fetched
using Object.class is at an upper level, and therefore won't be able to
"see" into a web application, each of which has its own ClassLoader.
Using "Category.class" would at least insure that the properties file is
searched for using the same class loader as was used to load the
log4j.jar.
If I make the change I suggest, then no matter where I put log4j.jar and
log4j.properties, the behaviour of the static initializer is as I expect
it to be.
Regards, Will
----- Original Message -----
From: "Fergus Gallagher" <[EMAIL PROTECTED]>
To: "LOG4J Users Mailing List" <[EMAIL PROTECTED]>
Cc: "'LOG4J Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Wednesday, May 30, 2001 12:46 PM
Subject: Re: Tomcat problem (again)
> When it comes to loading files from the classpath, note the difference
between
>
> myClass.getClassLoader().getResource()
>
> and
>
> myClass.getResource()
>
> The former loads wrt to the classpath root, but the latter loads wrt
to the
> location of the class bytecode file (typically).
>
> i.e., if myClass = com.acme.MyClass
>
> myClass.getClassloader().getResource("abc.def") =>
> <classpathroot>/abc.def
>
> myClass.getResource("abc.def") =>
<classpathroot>/com/acme/abc.def
>
> On the specific tomcat issue, if log4j.jar is in the tomcat top-level
> classpath ($TOMCAT_HOME/lib), then neither method will be able to
locate
> "log4j.properties" in <webapp>/WEB-INF/classes. The top-level
classloader
> has no access to the private web-app classpath, unless it's given an
> explicit handle.
>
> The solution is either to put log4j.jar and log4j.properties in the
tomcat
> classpath, OR both in the web-app. Any log4j.jar in the tomcat
classpath
> will take precedence.
>
> Fergus
>
> At 17:25 30/05/2001 +0100, Steve Meyfroidt wrote:
> >Hi,
> >
> >[[[A disclaimer: I've searched the archives for the solution to this
but
> >found nothing that I like. And Bugzilla is down too, so I'm sorry if
this
> >has been covered to death in this list.]]]
> >
> >I'm having trouble with init of log4j for a servlet running in
Tomcat. log4j
> >can't find the default config file, "log4j.properties".
> >
> >The reason for this appears to be that log4j looks for
> > static public final String DEFAULT_CONFIGURATION_FILE =
> >"log4j.properties";
> >by default, when it should really be looking for "/log4j.properties".
The
> >slash prefix is significant when loading resources from the
classpath. I
> >think this would solve the problems that I see other people have been
> >having.
> >
> >Has this been discussed? Am I on the right track? Is it a bug? Can I
submit
> >it?
> >
> >Regards,
> >Steve Meyfroidt
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
>
> --
> Fergus Gallagher
> Orbis
> http://www.orbisuk.com/
> +44-(0)20-8742 1600
>
>
> ---------------------------------------------------------------------
> 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]
