log4j/commons-logging issue?

[Facade]

Hi - I am deploying a war file to tomcat, and within the war there is
a jar file that uses log4j (via commons-logging). However I keep
getting

log4j:WARN No appenders could be found for logger
log4j:WARN Please initialize the log4j system properly.

The log4j.properties file is on the root of my jar file, and when I
did a
System.out.println(MyClass.getClass().getClassLoader().getResource("log4j.properties"))
I can see the file in my Jar file.

Whats wrong? Why can't JCL/Log4J see the same file?

Thanks.

 

[Mark Space]

Hi - I am deploying a war file to tomcat, and within the war there is
a jar file that uses log4j (via commons-logging). However I keep
getting

log4j:WARN No appenders could be found for logger
log4j:WARN Please initialize the log4j system properly.

The log4j.properties file is on the root of my jar file, and when I
did a
System.out.println(MyClass.getClass().getClassLoader().getResource("log4j.properties"))
I can see the file in my Jar file.

Whats wrong? Why can't JCL/Log4J see the same file?

Thanks.

Google?

http://logging.apache.org/log4j/1.2/manual.html

Quote:

Default Initialization Procedure

The log4j library does not make any assumptions about its environment.
In particular, there are no default log4j appenders. Under certain
well-defined circumstances however, the static inializer of the Logger
class will attempt to automatically configure log4j. The Java language
guarantees that the static initializer of a class is called once and
only once during the loading of a class into memory. It is important to
remember that different classloaders may load distinct copies of the
same class. These copies of the same class are considered as totally
unrelated by the JVM.

The default initialization is very useful in environments where the
exact entry point to the application depends on the runtime environment.
For example, the same application can be used as a stand-alone
application, as an applet, or as a servlet under the control of a
web-server.

The exact default initialization algorithm is defined as follows:

1. Setting the log4j.defaultInitOverride system property to any
other value then "false" will cause log4j to skip the default
initialization procedure (this procedure).
2. Set the resource string variable to the value of the
log4j.configuration system property. The preferred way to specify the
default initialization file is through the log4j.configuration system
property. In case the system property log4j.configuration is not
defined, then set the string variable resource to its default value
"log4j.properties".
3. Attempt to convert the resource variable to a URL.
4. If the resource variable cannot be converted to a URL, for
example due to a MalformedURLException, then search for the resource
from the classpath by calling
org.apache.log4j.helpers.Loader.getResource(resource, Logger.class)
which returns a URL. Note that the string "log4j.properties" constitutes
a malformed URL. See Loader.getResource(java.lang.String) for the list
of searched locations.
5. If no URL could not be found, abort default initialization.
Otherwise, configure log4j from the URL. The PropertyConfigurator will
be used to parse the URL to configure log4j unless the URL ends with the
".xml" extension, in which case the DOMConfigurator will be used. You
can optionaly specify a custom configurator. The value of the
log4j.configuratorClass system property is taken as the fully qualified
class name of your custom configurator. The custom configurator you
specify must implement the Configurator interface.

 

[Facade]

Google?

http://logging.apache.org/log4j/1.2/manual.html

Quote:

Default Initialization Procedure

The log4j library does not make any assumptions about its environment.
In particular, there are no default log4j appenders. Under certain
well-defined circumstances however, the static inializer of the Logger
class will attempt to automatically configure log4j. The Java language
guarantees that the static initializer of a class is called once and
only once during the loading of a class into memory. It is important to
remember that different classloaders may load distinct copies of the
same class. These copies of the same class are considered as totally
unrelated by the JVM.

The default initialization is very useful in environments where the
exact entry point to the application depends on the runtime environment.
For example, the same application can be used as a stand-alone
application, as an applet, or as a servlet under the control of a
web-server.

The exact default initialization algorithm is defined as follows:

    1. Setting the log4j.defaultInitOverride system property to any
other value then "false" will cause log4j to skip the default
initialization procedure (this procedure).
    2. Set the resource string variable to the value of the
log4j.configuration system property. The preferred way to specify the
default initialization file is through the log4j.configuration system
property. In case the system property log4j.configuration is not
defined, then set the string variable resource to its default value
"log4j.properties".
    3. Attempt to convert the resource variable to a URL.
    4. If the resource variable cannot be converted to a URL, for
example due to a MalformedURLException, then search for the resource
from the classpath by calling
org.apache.log4j.helpers.Loader.getResource(resource, Logger.class)
which returns a URL. Note that the string "log4j.properties" constitutes
a malformed URL. See Loader.getResource(java.lang.String) for the list
of searched locations.
    5. If no URL could not be found, abort default initialization.
Otherwise, configure log4j from the URL. The PropertyConfigurator will
be used to parse the URL to configure log4j unless the URL ends with the
".xml" extension, in which case the DOMConfigurator will be used. You
can optionaly specify a custom configurator. The value of the
log4j.configuratorClass system property is taken as the fully qualified
class name of your custom configurator. The custom configurator you
specify must implement the Configurator interface.

Hi Mark,
Google actually did not help, reason being, in my case the file is
already in the class path where as the stated solutions normally
suggest to add the file to the class path.
Thanks for the details on how log4j configures itself, but as I
said earlier, I am using commons-logging - which should take care of
configuring the log4j subsystem. Only thing else I can think of is,
apart from having log4j.properties in my jar file (where the actual
code doing the logging resides), I could attempt to put in WEB-INF/ -
all though technically speaking, the Classloader that loads the files
from the jar should be the same one that loads the War file.

--abbas

 

[Arne Vajhøj]

Hi - I am deploying a war file to tomcat, and within the war there is
a jar file that uses log4j (via commons-logging). However I keep
getting

log4j:WARN No appenders could be found for logger
log4j:WARN Please initialize the log4j system properly.

The log4j.properties file is on the root of my jar file, and when I
did a
System.out.println(MyClass.getClass().getClassLoader().getResource("log4j.properties"))
I can see the file in my Jar file.

Whats wrong? Why can't JCL/Log4J see the same file?

If I were to guess then log4j gets loaded by one of the parent
classloaders and that does not have your jar file with log4j.properties
in its classpath.

Arne