[
https://issues.apache.org/jira/browse/ZOOKEEPER-3737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044659#comment-17044659
]
Christopher Tubbs commented on ZOOKEEPER-3737:
----------------------------------------------
Thanks [~phunt], I will try setting that property. It looks like that won't
work in 3.4.14, because the class won't load (since
{{org.apache.log4j.jmx.HierarchyDynamicMBean}} isn't loaded dynamically, as it
is since 3.5.5). But, it should work in 3.5.5 and later.
Also, it seems there's a bug in the checking for log4j1. It is assuming log4j1
is available if the class {{org.apache.log4j.spi.LoggerRepository}} can be
loaded. However, that class is also available in the {{log4j-1.2-api}}
compatibility jar from log4j2. Since the class it actually needs is
{{org.apache.log4j.jmx.HierarchyDynamicMBean}}, it should probably be checking
for that instead, since that is not available in the log4j2 compatibility jar.
Then, the system property would not be necessary. However, the system property
should be a feasible workaround. I will try it.
> Unable to eliminate log4j1 transitive dependency
> ------------------------------------------------
>
> Key: ZOOKEEPER-3737
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3737
> Project: ZooKeeper
> Issue Type: Bug
> Components: jmx, server
> Affects Versions: 3.4.14, 3.5.7
> Reporter: Christopher Tubbs
> Priority: Major
>
> Apache Accumulo is trying to switch to using log4j2 only. However, this seems
> impossible, because ZooKeeper has a hard-coded dependency on log4j 1.2 for
> some sort of jmx thing. The following is the error and stack trace I get
> whenever I remove log4j 1.2 from the class path and try to run a test
> instance of ZooKeeper as part of Accumulo's build test suite.
> {code}
> 2020-02-24T20:10:03,682 [jmx.ManagedUtil] ERROR: Problems while registering
> log4j jmx beans!
> java.lang.ClassNotFoundException: org.apache.log4j.jmx.HierarchyDynamicMBean
> at
> jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
> ~[?:?]
> at
> jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> ~[?:?]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:521) ~[?:?]
> at java.lang.Class.forName0(Native Method) ~[?:?]
> at java.lang.Class.forName(Class.java:315) ~[?:?]
> at
> org.apache.zookeeper.jmx.ManagedUtil.registerLog4jMBeans(ManagedUtil.java:72)
> ~[zookeeper-3.5.7.jar:3.5.7]
> at
> org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:94)
> ~[zookeeper-3.5.7.jar:3.5.7]
> at
> org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:64)
> ~[zookeeper-3.5.7.jar:3.5.7]
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:?]
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> ~[?:?]
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> ~[?:?]
> at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
> at org.apache.accumulo.start.Main.lambda$execMainClass$1(Main.java:167)
> ~[accumulo-start-2.1.0-SNAPSHOT.jar:2.1.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
> I know previous work has been done on ZOOKEEPER-850 and ZOOKEEPER-1371 to
> eliminate the use of log4j in the source, but this work does not appear to be
> complete, since it is still required at runtime (at least, for the server...
> but maybe for the client too... it's hard to tell from the way Accumulo runs
> its test suite, and I'm not super familiar with ZK internals).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
