-
Notifications
You must be signed in to change notification settings - Fork 2.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[NO-ISSUE] Use reload4j instead of log4j #4719
Conversation
@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. |
@@ -114,8 +114,7 @@ | |||
<plugin.frontend.version>1.12.1</plugin.frontend.version> | |||
|
|||
<!-- common library versions --> | |||
<slf4j.version>1.7.30</slf4j.version> | |||
<log4j.version>1.2.17</log4j.version> | |||
<slf4j.version>1.7.35</slf4j.version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not 1.7.36?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the elaboration, that makes sense.
@@ -240,12 +239,6 @@ | |||
<version>${slf4j.version}</version> | |||
</dependency> | |||
|
|||
<dependency> | |||
<groupId>log4j</groupId> | |||
<artifactId>log4j</artifactId> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
I built zeppelin-distribution/target/zeppelin-0.11.0-SNAPSHOT.tar.gz locally with these changes and log4j jar was not in the dist. |
This reverts commit d0a71c7.
(cherry picked from commit d0a71c7)
What is this PR for?
What type of PR is it?
Bug Fix
Improvement
Feature
Documentation
Hot Fix
Refactoring
Please leave your type of PR only
Todos
What is the Jira issue?
How should this be tested?
Screenshots (if appropriate)
Questions: