[
https://issues.apache.org/jira/browse/ZOOKEEPER-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15053160#comment-15053160
]
Chris Nauroth commented on ZOOKEEPER-2342:
------------------------------------------
System administrators will consider it unacceptable if we ship a product that
has logging broken by default. I just caught up on the full thread of
ZOOKEEPER-1371, and it seems this point was lost in the lengthy (multi-year)
course of discussion.
At some point in the lifetime of that patch, someone did consider this, because
the documentation part of the patch stated that we ship the Log4J binding by
default for backwards compatibility. The documentation also still references
use of log4j.properties to control logging.
{code}
<section id="sc_logging">
<title>Logging</title>
<para>
ZooKeeper uses <emphasis role="bold"><ulink
url="http://www.slf4j.org";>SLF4J</ulink></emphasis>
version 1.7 as its logging infrastructure. For backward compatibility
it is bound to
<emphasis role="bold">LOG4J</emphasis> but you can use
<emphasis role="bold"><ulink
url="http://logback.qos.ch/";>LOGBack</ulink></emphasis>
or any other supported logging framework of your choice.
</para>
<para>
The ZooKeeper default <filename>log4j.properties</filename>
file resides in the <filename>conf</filename> directory. Log4j requires
that
<filename>log4j.properties</filename> either be in the working directory
(the directory from which ZooKeeper is run) or be accessible from the
classpath.
</para>
<para>For more information about SLF4J, see
<ulink url="http://www.slf4j.org/manual.html";>its manual</ulink>.</para>
<para>For more information about LOG4J, see
<ulink
url="http://logging.apache.org/log4j/1.2/manual.html#defaultInit";>Log4j Default
Initialization Procedure</ulink>
of the log4j manual.</para>
</section>
{code}
The patch implementation doesn't match the documentation though, so logging is
broken.
I see 2 possible solutions.
# Reintroduce the Log4J 1 binding as a runtime dependency. This choice retains
backwards-compatibility with existing deployments that use log4j.properties to
control their logging.
# Include the Log4J 2 binding as a runtime dependency. This choice is not
backwards-compatible, because the configuration format has changed in a
non-backwards-compatible way in Log4J 2
http://logging.apache.org/log4j/2.x/manual/configuration.html
If we go with Log4J 2, then it must be done within the alpha timeline, because
we have stated a plan of stopping backwards-incompatible changes once 3.5
produces a beta release.
However, we would never write new code directly to the Log4J API (either
version 1 or version 2). It would only ship in the distro as a runtime
dependency.
Overall, I suppose now is the time to jump to Log4J 2, considering version 1 is
end of life. We probably won't get another opportunity for a
backwards-incompatible change of this magnitude for a long time.
Could others please chime in too before we proceed with any changes?
> ZooKeeper cannot write logs, because there is no SLF4J binding available on
> the runtime classpath.
> --------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-2342
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2342
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Chris Nauroth
> Priority: Blocker
> Fix For: 3.5.2, 3.6.0
>
>
> ZOOKEEPER-1371 removed our source code dependency on Log4J. It appears that
> this also removed the Log4J SLF4J binding jar from the runtime classpath.
> Without any SLF4J binding jar available on the runtime classpath, the it is
> impossible to write logs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
