You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by "Hansen, Richard" <Ri...@westgroup.com> on 2001/05/04 17:43:38 UTC

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: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org


Re: log4j.properties file location bug?

Posted by Robert Burrell Donkin <Ro...@appleonline.net>.
Scott M Stark wrote:

> Using a file resource in a web-app descriptor means that one has to potentially
> change the file property for each deployment. Its much easier to be able to load
> the log4j.properties as a resource from the classpath than a file imho.

if you're using a 2.3 complaint container (eg. tomcat 4) then a good way is to use a
ServletContextListener and configure log4j using a resouce InputStream loaded from a webapp-relative URL
when the context is created.

- robert





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


Re: log4j.properties file location bug?

Posted by Scott M Stark <Sc...@displayscape.com>.
Using a file resource in a web-app descriptor means that one has to potentially
change the file property for each deployment. Its much easier to be able to load
the log4j.properties as a resource from the classpath than a file imho. You
also may not even have access to a file system because logging is occurring
from a component that was downloaded from the net. Reliance on Files is
not a distributed computing friendly thing.

>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.

The recommended way for specifying the properties file is in the web.xml file for your web-app. As in:

<web-app>
  <servlet>
    <servlet-name>XYZ</servlet-name>
    <servlet-class>com.foo.bar.XYZ</servlet-class>
    <init-param>
      <param-name>log4j.configuration</param-name>
      <param-value>file:///c:/log4j.xml</param-value>
    </init-param>
  </servlet>


  <servlet-mapping>
    ....
  </servlet-mapping>

  ...
</web-app>

This is imho a lot more hassle free. Or?

>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/ .)

Thanks. I am aware of the link. Ceki

>Regards, Will
>
>----- Original Message -----
>From: "Hansen, Richard" <Ri...@westgroup.com>
>To: "LOG4J Users (E-mail)" <lo...@jakarta.apache.org>
>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: log4j-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org

--
Ceki Gülcü


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




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


Re: log4j.properties file location bug?

Posted by Ceki Gülcü <cg...@qos.ch>.
At 12:29 07.05.2001 -0400, you wrote:
>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.

Agreed. It used to be that the call was

  } catch (MalformedURLException ex) {
          url = Loader.getResource(resource, Category.class); 
  }     
      
I changed it to Object.class in order to avoid a JarIndexFileException. This was probably a silly move on my part. I keep screwing this up! Let me see what I can do to solve this issue once an for all.

>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.

Right. 

>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.

The recommended way for specifying the properties file is in the web.xml file for your web-app. As in:

<web-app>
  <servlet>
    <servlet-name>XYZ</servlet-name>
    <servlet-class>com.foo.bar.XYZ</servlet-class>
    <init-param>
      <param-name>log4j.configuration</param-name>
      <param-value>file:///c:/log4j.xml</param-value>
    </init-param>
  </servlet>


  <servlet-mapping>
    ....
  </servlet-mapping>

  ...
</web-app>

This is imho a lot more hassle free. Or?

>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/ .)

Thanks. I am aware of the link. Ceki

>Regards, Will
>
>----- Original Message -----
>From: "Hansen, Richard" <Ri...@westgroup.com>
>To: "LOG4J Users (E-mail)" <lo...@jakarta.apache.org>
>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: log4j-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org

--
Ceki Gülcü


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


Re: log4j.properties file location bug?

Posted by William Jaynes <wj...@mediaone.net>.
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" <Ri...@westgroup.com>
To: "LOG4J Users (E-mail)" <lo...@jakarta.apache.org>
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: log4j-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-user-help@jakarta.apache.org
>


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


RE: log4j.properties file location bug?

Posted by Jeet Marwah <jm...@datalinx.net>.
Hi ,
What u have done is right? The reason is that u must be using the Properties
class and must be passing the obj to the log4j configurator.

U can put ur config file in any folder that u want and if u are using the
Properties class , the following things can be done:
1) set the classpath to that folder which has that properties file. For eg :
let the folder be c:\log4j
set classpath = %classpath%;c:\log4j

2) Assuming the package u are developing is "net.java". in the folder
c:\log4j. So the final directory stucutre is :
c:\log4j\net\java and the file is in this
folder(c:\log4j\net\java\config.txt)

2) Use the following code:

		try
		{

			InputStream isLog4j =
getClass().getResourceAsStream("/net/java/config.txt");
			Properties propsLog4j = new Properties();
			propsLog4j.load(isLog4j);
			isLog4j.close();

			//For getting the config file - for log4j
			PropertyConfigurator.configure(propsLog4j);
		}
		catch(Exception e) { e.printStackTrace(); }

Hope this is of some help to u.

This is how u may not require to hard code the absolute path of the config
file.

Bye ,
Jeet.




-----Original Message-----
From: Hansen, Richard [mailto:Richard.Hansen@westgroup.com]
Sent: Friday, May 04, 2001 11:44 AM
To: LOG4J Users (E-mail)
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: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org


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