Update Dependency Versions: Woodstox 6.4.0, Scala-lang 2.13.9, Jackson-Databind 2.14.0

[stephen-crawford]

Signed-off-by: Stephen Crawford [email protected]

Description

Fixes a remaining dependency to Woodstox 6.2.6 library as a follow-up to #2197. I incorrectly looked at only the direct dependencies previously not accounting for the transient dependencies introduced by other libraries. This force should make the Woodstox version match the desired 6.4.0.

I also corrected the versions for jackson_databind, kafka, and snakeyaml.

Issues Resolved

Further resolves the Woodstox dependency problem.

Testing

After the change, runnning ./gradlew dependencies shows all references to Woodstox-core being bumped to 6.4.0 and all the other WhiteSource issues being fixed.

Check List

• New functionality includes testing
• [] New functionality has been documented
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[stephen-crawford]

@cwperks @DarshitChanpura this build failure does not seem related to the changes made in this commit. What do you guys think?

[DarshitChanpura]

I was just going through the test failures and I agree

[DarshitChanpura]

I've triggered a re-run to see if it was one-off failure, cause most of the tests are failing due to Address already in use error

[cwperks]

@DarshitChanpura 1.3 build is known to be flaky - #2023

It may take a couple of retries.

[DarshitChanpura]

okay.. do we want to proceed with merge @cwperks ?

[cwperks]

@DarshitChanpura Let's make sure this PR and the one against 1.x match. I don't think we need snakeyaml listed in here and we may not need netty in the section either, but I'd like to wait for an updated SNAPSHOT from core and then re-run the CI to see what version of netty it would resolve to without forcing the resolution strategy. If we need to force the resolution strategy than that is fine, but it would be nice to have a mechanism to know when there is a version mismatch with the version in core's version.properties.

[cwperks]

Actually this can be done locally as well.

If you checkout version 1.3 of core locally and run the following:

./gradlew assemble
./gradlew publishToMavenLocal

once those are complete switch to the patch for 1.3 of security and run

./gradlew clean assemble

That should produce a .zip in build/distributions

From there you check what jars are included for snakeyaml and netty.

[DarshitChanpura]

@scrawfor99 Were you able to test the behavior with the steps @cwperks mentioned?

[stephen-crawford]

@DarshitChanpura, no because I cannot use my Mac (1.3 does not work on M1) to test it and I am getting errors trying to create a new remote desktop currently. I tried two different accounts and various settings with no avail so am going to table it for now. It should not be too big a change either way once it is testable.

[stephen-crawford]

Update: I am away for the remainder of the day for travel but I will be confirming this works tomorrow and updating accordingly. I did set up a linux remote desktop to test this.

[cwperks]

Confirmed via creating a local snapshot of the latest from 1.3 of core and publishing to maven local. It is not necessary to force the netty resolution as it will resolve to the version of netty from core. This will make maintenance easier because it will not require an update every time core updates the netty dependency.

[codecov-commenter]

Codecov Report

Merging #2270 (2f80076) into 1.3 (d002416) will increase coverage by 0.04%.
The diff coverage is 95.65%.

@@             Coverage Diff              @@
##                1.3    #2270      +/-   ##
============================================
+ Coverage     64.66%   64.71%   +0.04%     
- Complexity     3218     3221       +3     
============================================
  Files           247      247              
  Lines         17350    17353       +3     
  Branches       3087     3087              
============================================
+ Hits          11220    11230      +10     
+ Misses         4582     4579       -3     
+ Partials       1548     1544       -4     

Impacted Files	Coverage Δ
...pensearch/security/securityconf/ConfigModelV7.java	64.46% <95.65%> (+0.56%)	⬆️
...security/auditlog/sink/InternalOpenSearchSink.java	69.23% <0.00%> (-11.54%)	⬇️
...a/org/opensearch/security/tools/SecurityAdmin.java	47.59% <0.00%> (-0.14%)	⬇️
.../dlic/auth/ldap2/LDAPConnectionFactoryFactory.java	58.01% <0.00%> (+1.52%)	⬆️
...security/configuration/DlsFlsFilterLeafReader.java	62.11% <0.00%> (+1.64%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[stephen-crawford]

For the BindExceptions resulting in failing tests, it looks like they may have been fixed by the incorporation of a doThenWait method used in the auditlog tests and perhaps some others. This screenshot shows a git diff between the 1.3 branch and the 2.3.0 branch which does not have this issue. To me it seems like the fix was either a part of a change to the testing strategy overall--how the tests are run--or a change to the tests that were failing.

This seems like a change to the tests that were failing that could have fixed things.

These changes were introduced in #1758. So I think it may be worthwhile backporting them into 1.3 and then seeing if that fixes the issue. Note that the PR is flagged for backport to 1.3 but that backport never actually happened #1796.

@cwperks @DarshitChanpura

[cwperks]

@scrawfor99 Thank you for looking into CI stability on the 1.3 branch. Can you do the manual backport and test to see if it improves CI stability for 1.3?

[stephen-crawford]

@cwperks thank you for rerunning the failures as needed until things passed. I looked into the issue and the backport is complicated. I suspect that is why it did not happen in the first place. I am going to create an issue for the changes to be backported. After resolving the basic issues with the backport I encountered a problem where the new logic expects to be able to find various files in auditlog/ however I do not think this folder exists in the earlier version.