Pros:
• log4j is optimized for speed. The burden of logging is minimized.
• log4j is based on a named logger hierarchy.
• log4j is thread-safe.
• The format of the logged message can be specified similar to C language’s printf()
function. For e.g. Formatting can be specified as “%r [%t] %-5p %c{2} %x - %m\n”
• log4j is not restricted to a predefined set of facilities.
• Logging behavior can be set at runtime using a configuration file. Configuration files can
be property files or in XML format.
• log4j is designed to handle Java Exceptions from the start.
• log4j can direct its output to a file, the console, a java.io.OutputStream, java.io.Writer, a
remote server using TCP, a remote Unix Syslog daemon, to a remote listener using JMS,
to the NT EventLog or even send e-mail.
• The format of the log output can be easily changed by extending the Layout class. The
target of the log output as well as the writing strategy can be altered by implementations
of the Appender interface.
• log4j supports multiple output appenders per logger.
• It supports hierarchical logging. It is possible to select (at runtime) which log statements
are output at arbitrary granularity. Users can choose to implement their own log formats
and output strategies.

Cons:
• Internationalization (Though specified in features, it is not mentioned anywhere else in
the documentation) is not provided
• Asynchronous logging facility is not provided
• Threads are used in Handler objects. As threads should be managed only by the EJB
container and should not be created in the code written by a developer, we have to find a
workaround for this issue. The solutions like writing Java Messaging Service handler or
calling the initialization code of the framework from start-up classes of application server
need more investigation.