[NO-ISSUE] Use reload4j instead of log4j

[pjfanning]

What is this PR for?

• reload4j does not prevent us moving to log4jv2 later
• reload4j fixes some security issues in log4j
• it doesn't feel great for an ASF project to still be using insecure logging frameworks like log4j v1

What type of PR is it?

Bug Fix
Improvement
Feature
Documentation
Hot Fix
Refactoring
Please leave your type of PR only

Todos

• - Task

What is the Jira issue?

• Open an issue on Jira https://issues.apache.org/jira/browse/ZEPPELIN/
• Put link here, and add [ZEPPELIN-Jira number] in PR title, eg. [ZEPPELIN-533]

How should this be tested?

• Strongly recommended: add automated unit tests for any new or changed behavior
• Outline any manual steps to test the PR here.

Screenshots (if appropriate)

Questions:

• Does the license files need to update?
• Is there breaking changes for older versions?
• Does this needs documentation?

[pjfanning]

@jongyoul is this something that could be merged? I know log4jv2 is under consideration but log4jv1 is a really bad thing to have a dependency and it is much simpler to use reload4j. Some of the big Zeppelin dependencies already use reload4j - making it more complicated for Zeppelin to use log4jv2.

[pan3793]

why not 1.7.36?

[pjfanning]

causes a maven convergence issue - due to other dependencies of zeppelin using 1.7.35

I can try further changes but it could take a few days.

The key thing is to get agreement that keeping log4jv1 is not a good thing and that reload4j is a reasonable short term change to avoid using a completely insecure logging framework.

[pan3793]

thanks for the elaboration, that makes sense.

[pan3793]

removing the definition from dependencyManagement does not mean excluding the jar from the final binary tarball, there is still a chance that log4j is collected as the transitive dependency into the final tarball, additional manual checks are required.

[pjfanning]

I'll have a better look over the next day or 2 to see what transitive dependencies could leaking log4j dependencies into zeppelin. There already appears to be issues (pre-existing issues unrelated to this change) where log4j and log4j-1.2-api are conflicting. log4j-1.2-api is a log4jv2 jar that pretends to be log4jv1 and you shouldn't have this on the classpath at the same time as you have the legacy log4j jar.

[pjfanning]

I built zeppelin-distribution/target/zeppelin-0.11.0-SNAPSHOT.tar.gz locally with these changes and log4j jar was not in the dist.

[pjfanning]

@jongyoul @pan3793 @Reamer could this PR be merged? The ASF is suffering damage to our reputation by having project's who won't use secure libraries - in particular old versions of log4j make us look really bad.