Here is a list of commonly encoutered problems when using log4j:
The reason for observing duplicates in log4j output is either due
to having added the same appender multiple times to the same category
(typically root) or having added the same appender to different
categories not knowing that appenders are inherited cumulatively.
log4j does not eliminate appender duplicates. In other words, if
you add the same appender to a categoty n times, that appender
will be invoked n times to append to its target.
A slightly different cause is adding different appenders all
sharing the same underlying output target to some category. In the
most common occurance of this phenomenon, the
BasicConfigurator.configure() method is invoked multiple times. Each
time it is invoked, this method adds an appender with a
One other common mistake is to forget that appenders are inherited
cumulatively from the hierarchy. For example, if you add an appender,
say The spaces in the value, i.e. In log4j version 0.9.0, all spaces are removed from both
ends of option values. In version 0.9.1 log4j reverted to the old
behaviour where option values are not all automatically trimmed.
You can remedy this problem by disabling the JIT compiler and by
compiling the code without the -O option.
See [Support
#108314] for an example of this problem.
This exception is thrown because log4j does not support
homonyms. For example, the following will systematically throw a
By default, the log4j tells me to initialize properly.
Logging output is written to a target by using an appender. If no
appenders are attached to a category nor to any of its ancestors, you
will get the following message when trying to log:
log4j: No appenders could be found for category (some.category.name).
log4j: Please initialize the log4j system properly.
Log4j does not have a default logging target. It is the
user's responsability to ensure that all categories can inherit an
appender. This can be easily achieved by attaching an appender to the
root category.
Duplicates in log4j output.
System.out target to the root category. See [
Support #107779] for an example.
A, to the root category, all other categories will
inherit A as an appender. Thus, if you add A
to a categoy, say C, then an enabled statement of
category C, will print to A twice, once
because A is in root and once because it is in
C. See [
Bug #121892 ] for an example.
Options are not parsed correctly.
The PropertyConfigurator relies on java.util.Properties
class to read in the configuration file. This class preserves spaces
in options. For example,
fruit=orange
is returned as an option having the key "fruit" and the
value "orange ".
"orange ", are due to
invisible spaces at the end of the example shown above. Thus, some of
the options might not be interpreted correctly due to trailing
spaces. See [Bug
#121903] for an example of this problem.
Location information is printed as a "?" character.
Location information is extracted automatically by the PatternLayout
conversion patterns %C, %F, %M and %L. However, some just-in-time
(JIT) compilers make it impossible to extract location information. It
is also possible that the complier that generated the byte code may
have ommitted the LineNumber table as is done by -O option of javac
and jikes.
ClassCastException when instantiating
a Category subclasses.ClassCastException
Category c1 = Category.getInstance("bad");
MyCategory c2 = (MyCategory) MyCategory.getInstance("bad");
where MyCategory is a sub-class of
Category. The problem occurs because the second
getInstance invocation will retrieve the category created
in the fist invocation. This instance is a Category
object and cannot be cast to MyCategory.
PropertyConfigurator will create and
configure org.log4j.Category objects. Thus, if you try to
instantiate a category sub-class for an already existing category, and
try to cast it to the sub-class type, you will systematically get a
ClassCastException.
To address this problem, the PropertyConfigurator admits the