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
[BEAM-11055] Update log4j to version 2.14.1 #13073
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.
Please, take a look on failed tests. Some of them (at least Java PreCommit
) were failed because of this change.
ea7eeef
to
3f385bd
Compare
I missed some places so it became a bit unstable, let's see if it is ok now. |
Do we really need to have so many places where the same version is defined? Couldn't be better to extract this into |
I hesitated to do this because the references defined in |
@iemejia Yes, this is not our default logging library but since it's a library that is used in different modules (and seems the same version everywhere), then I'd prefer to extract it as we do for other libraries as well. In any case, the version can be overridden in case if module will need another version. |
3f385bd
to
2416310
Compare
@@ -23,53 +23,54 @@ package org.apache.beam.gradle | |||
*/ | |||
class GrpcVendoring_1_26_0 { | |||
|
|||
static def guava_version = "26.0-jre" |
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.
This one and the next one are only sorting stuff to make it more easy to find the refs.
static def jboss_marshalling_version = "1.4.11.Final" | ||
static def jboss_modules_version = "1.1.0.Beta1" | ||
static def jzlib_version = "1.1.3" | ||
static def log4j_version = "2.13.3" |
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.
Notice that vendored grpc dependencies can have different versions so they don't depend on Beam main module file, so versions are defined independently.
2416310
to
88baac3
Compare
Done suggested changes can you PTAL again @aromanenko-dev |
88baac3
to
c46bed5
Compare
@iemejia Thanks! Could you take a look on failed tests? Looks like that some of them are caused by this change. |
c46bed5
to
342b7e9
Compare
Arrghh I executed by mistake the |
retest this please |
Unfortunately, there are still failing Java tests, not sure that Python one is related. |
342b7e9
to
b62612d
Compare
b62612d
to
d0c620e
Compare
This PR is breaking on the HCatalog module with a I tried to run Google's Linkage Checker to find the issue but it seems also that the tool configuration is broken on Beam current master (double checked by Alexey) when used with the hcatalog module. @suztomo sorry to bother you, but I am absolutely puzzled about the issue here and I was wondering if you could have a hint on what is going on. Also I suppose you could help us check what is going on with the linkage check since you mentioned some months ago it was working now on the HCatalog module. Notice that Beam recently upgraded to gradle 6.6 so maybe something was broken as part of that. |
Interesting. Let me see.
Reproduce ProblemThe command below reproduces the problem. It's strange that Gradle marks it successful:
Found ignoreFailures in the build.gradle:
Turning it off. TestRuntimeClasspathhttps://gist.github.com/suztomo/63d6104d054d80370cd9e34f64e4d13e As per IntelliJ,
I don't know why Gradle does not supply the missing class from org.apache.logging.log4j:log4j-core:2.13.3 when it runs the test. |
With some debug output, I see the Gradle supplies the ReflectionUtil class when the class runs. I'm now feeling that the EmbeddedMetastoreService runs with a special class path. Edit: My intelliJ is complaining it too. Now I know that this case involves two fully-qualified class names:
|
Argh! I was afraid of that too, It clearly looks like a different classpath issue, that will explain why it breaks so weirdly. I think the simplest solution would be to let that module to provide its own log4j. The part that still does not make any sense to me is how the hcatalog module in Beam ends up resolving the new version of log4j? Can you spot which dependency is overwriting the version ? From a look at the module build.gradle file I don't see any of the Beam dependencies of hcatalog requiring log4j. I have checked in the gradle scan too and I just cannot see who is doing it |
BeamModulePlugin.groovy
log4j-api-2.4.1.jar had the missing class, while log4j-api-2.13.3.jar does not have it.
It seems that org.slf4j:slf4j-log4j12:1.7.30 has |
d0c620e
to
512c432
Compare
@suztomo thanks for the pointer I was not aware we were forcing dependencies, but does forcing all dependencies make even sense? The exclusion I am doing at the hcatalog module in this PR feels hacky specially because log4j is a dependency none of the Beam modules require it is only required by transitive dependencies. I saw your work on BEAM-9542 #11168 but it seems that the change to support the GCP BoM undid it, was this intentional? |
512c432
to
c65b034
Compare
My attempt #11168 was not merged. (As per my comment there, I had to upgrade google-api-client at that time and didn't get a chance to come back.) |
I see, good to know there is awareness on the issue, thanks @suztomo. I wonder now if my forcing fix makes even sense since this PR has two goals (1) upgrade the dependency and (2) silence automatic security detectors from reporting this dependency as a security issue which clearly won't be the case at least for the hcatalog module if I force the previous version even if this is not at all a Beam problem. WDYT @aromanenko-dev shall we upgrade as it is to cover (1) for most of the other modules knowing that (2) would still be an issue for HCatalog? |
c65b034
to
25df3a2
Compare
1958090
to
5f82918
Compare
@@ -41,6 +41,17 @@ test { | |||
ignoreFailures true | |||
} | |||
|
|||
configurations.testRuntimeClasspath { | |||
resolutionStrategy { | |||
def log4j_version = "2.4.1" |
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.
Somehow I had to redefine this here to make it work, bad to have this repeated but it is the only workaround I could find.
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.
Should this be 2.14.1 ?
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.
Arghh what a silly mistake, my excuses I opened #14751 to upgrade this dep to the minimum compatible version with Hive dependencies, wondering if we should also cherry-pick it for the release. Thanks for noticing @aaltay !
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.
It is a pity we cannot move to the latest log4j version because of Hive's HCatalog dependency constraints. The bad part is that this will still trigger security analysis tools warnings, but I have no idea of how to workaround this apart of doing a full upgrade of Hive to the latest but that does not seem to be so simple either, for ref BEAM-9351.
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.
Thank you @iemejia. I do not have an opinion about cherry picking to the release or not. If it helps, I am not aware of any user issues or bug reports. I noticed this coincidentally.
5f82918
to
8a24eb8
Compare
Run Java PostCommit |
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.
LGTM, thanks!
force "org.apache.logging.log4j:log4j-api:$log4j_version" | ||
force "org.apache.logging.log4j:log4j-core:$log4j_version" | ||
force library.java.log4j_api | ||
force library.java.log4j_core |
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 think this is no longer necessary with the change to library
in BeamModulePlugin.groovy
. applyJavaNature
does this for all dependencies in library
:
beam/buildSrc/src/main/groovy/org/apache/beam/gradle/BeamModulePlugin.groovy
Lines 1537 to 1544 in 3c9807b
if (config.getName() != "errorprone" && !inDependencyUpdates) { | |
config.resolutionStrategy { | |
// Filtering versionless coordinates that depend on BOM. Beam project needs to set the | |
// versions for only handful libraries when building the project (BEAM-9542). | |
def librariesWithVersion = project.library.java.values().findAll { it.split(':').size() > 2 } | |
force librariesWithVersion | |
} | |
} |
R: @aromanenko-dev