-
Notifications
You must be signed in to change notification settings - Fork 3.4k
HBASE-26691 Replacing log4j with reload4j for branch-2.x #4050
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
Conversation
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.
does it also ban transitive dependencies on log4j and slf4j-log4j12?
Yes, if you do not want to ban transitive dependency, just add |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
The latest reload4j version is 1.2.18.3 with a few additional vulnerabilities fixed. |
🎊 +1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
💔 -1 overall
This message was automatically generated. |
@@ -426,42 +350,6 @@ | |||
</dependencies> | |||
|
|||
</profile> | |||
|
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'm not sure about this part, but the rest LGTM
Basically in addition to replacing reload4j, the PR also simplifies dependency management. |
can you also verify the test failure is unrelated? |
I am testing my Hadoop reload4j patch, and then realized there are a lot of gotchas when building downstream applications. |
For HBase we have tried out best to not introduce log4j dependencies to our downstream users, they will only pull in slf4j, so I do not think it will break our users too much. But it is true that hadoop and zookeeper will introduce log4j and slf4j-log4j12 dependencies to downstreamer users, I suggest we do a round of cleanup, to avoid introducing these dependencies. Thanks. |
@@ -220,6 +220,24 @@ | |||
<scope>compile</scope> | |||
<optional>true</optional> | |||
</dependency> | |||
<dependency> |
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.
Is this related?
@@ -322,100 +340,6 @@ | |||
</property> | |||
</activation> | |||
<dependencies> | |||
<dependency> |
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.
Oh, I see, some extra refactoring?
<type>test-jar</type> | ||
<scope>compile</scope> | ||
<exclusions> |
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 don't have a strong opinion about this so will approve the PR but it would be better to stick with just the changes that are implied by the description [HBASE-26691 Replacing log4j with reload4j for branch-2.x]
If there are no more concerns or updates, I will merge this tomorrow. |
So do we plan to use reload4j for 2.x, or we plan to directly upgrade to log4j2? |
how about we get this in place for branches-2 now, so that we can stop shipping hbase 2 releases with an EOL log4j 1, but we plan for the log4j 2 changes to be the preferred path for whatever the next minor 2.x release is after the backport lands. (presuming the testing goes well.) |
Fine by me~ |
Merged. Agreed, we can do this now and I will pick it all the way back to branch-2.4, and anytime we can commit log4j2 work when ready to branch-2.5 and branch-2. |
Signed-off-by: Andrew Purtell <apurtell@apache.org> Conflicts: pom.xml
Signed-off-by: Andrew Purtell <apurtell@apache.org>
I also committed an addendum that ups the reload4j version to the latest release at this time, 1.2.19, and fixes a couple of misses in shading and assembly configuration. |
<groupId>org.apache.hadoop</groupId> | ||
<artifactId>hadoop-minicluster</artifactId> | ||
<scope>test</scope> | ||
</dependency> |
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.
The child POM does not inherit the exclusion of the dependency introduced by the parent POM. Is the reconstruction safe? What are the considerations for deleting the exclusions?
No description provided.