You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Chris Nauroth (JIRA)" <ji...@apache.org> on 2016/01/04 21:52:39 UTC

[jira] [Updated] (ZOOKEEPER-2342) ZooKeeper cannot write logs, because there is no SLF4J binding available on the runtime classpath.

     [ https://issues.apache.org/jira/browse/ZOOKEEPER-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Nauroth updated ZOOKEEPER-2342:
-------------------------------------
    Attachment: ZOOKEEPER-2342.001.patch

I'm attaching a v001 patch for a migration to Log4J 2, based on my reading of the Log4J 2 [Configuration|http://logging.apache.org/log4j/2.x/manual/configuration.html] guide.  Here is a summary of the changes.

# Some of the ZOOKEEPER-1371 build script changes are partly rolled back.  We no longer need a {{junit.run.nolog4j}} target.  This was kind of bogus anyway, because there aren't really any test suites that match the {{NoLog4J*.java}} pattern.
# The top-level ivy.xml prevents the Log4J 2 dependencies from leaking into client applications via transitive dependency.
# Delete all log4j.properties files and replace them with a roughly equivalent log4j2.properties file.   (More on this later.)  We now need to use system property {{log4j.configurationFile}} to refer to it.  I added a log4j2.properties to some components that didn't previously have a log4j.properties, so they can log correctly now.
# Several tests depended on programmatic access to the Log4J API for capturing and verifying log messages.  I updated this code to the new Log4J 2 APIs.

This revision of the patch has not yet updated documentation.

I have verified that all tests are passing and emitting logs.  I also built the distro and verified successful logging from zkServer.sh and zkCli.sh.

I'm not completely satisfied with this.  With Log4J 1, we were able to parameterize which appender to attach to the root logger by substituting the {{zookeeper.root.logger}} property with something like {{INFO, CONSOLE}} or {{INFO, ROLLINGFILE}}.  It appears this is not as easily controlled in Log4J 2, where the configuration is more structured and switching appenders requires more changes in the configuration file.  For this first revision of the patch, the log4j2.properties is logging to both the {{CONSOLE}} and {{ROLLINGFILE}} appenders, which isn't desirable for the final solution.  I'm attaching this version of the patch anyway to see if anyone else has ideas on how to achieve a configurable split.

I also have not yet replicated the functionality of the zookeeper_trace.log from our log4j.properties file.

> 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
>            Assignee: Chris Nauroth
>            Priority: Blocker
>             Fix For: 3.5.2, 3.6.0
>
>         Attachments: ZOOKEEPER-2342.001.patch
>
>
> 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)