Bump com.fasterxml.jackson:jackson-bom from 2.17.0 to 2.17.1

[mariofusco]

This pull request bump Jackson from 2.17.0 to 2.17.1 replacing this automatically generated one.

In this release Jackson changed the default RecyclerPool implementation ( see FasterXML/jackson-core@2a4a6dc ) because of some problems we found in the LockFree version. At the moment they decided to revert back to the ThreadLocal-based implementation, the non-friendly one for virtual thread, so very likely this will be changed again in the near future.

For this reason I believe that the test checking for the default pool implementation currently in use by Jackson, that has been introduced with this commit, is brittle and I removed it. That test was necessary to check that the VertxHybridPoolObjectMapperCustomizer was behaving as expected, replacing the RecyclerPool implementation only when the user hasn't explicitly configured a pool that is different from the default one. I changed the VertxHybridPoolObjectMapperCustomizer so that it now compares the RecyclerPool implementation in use with the Jackson's default one, thus making the test that I removed no longer necessary.

As a side note it seems odd to me that Quarkus uses a version of jackson-core that is different from the one used by Vert.x, which is still depending on Jackson 2.16.1. Is this expected?

/cc @franz1981 @gsmet @vietj @geoand

[franz1981]

With my commit I have added a unit test, so I suggest to update it, to help capturing regressions on quarkus version which could observe different Jackson versions

[franz1981]

I've now see what Jackson does at https://github.com/FasterXML/jackson-core/blob/jackson-core-2.17.1/src/main/java/com/fasterxml/jackson/core/util/JsonRecyclerPools.java#L31-L41 so there won't be any allocation apart from https://github.com/FasterXML/jackson-core/blob/jackson-core-2.17.1/src/main/java/com/fasterxml/jackson/core/util/JsonRecyclerPools.java#L127 which is negligible (class loading apart, but that was happening in my pr as well!); thanks @mariofusco now that there is no default pool allocation, this one is way more robust!

[franz1981]

LGTM thanks @mariofusco well done!

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 9df2843.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.

---

Flaky tests - Develocity

⚙️ Maven Tests - JDK 17 Windows

📦 integration-tests/maven

✖ io.quarkus.maven.it.TestMojoIT.testThatTheTestsAreReRunMultiModule - History

• Condition with Lambda expression in io.quarkus.maven.it.continuoustesting.TestModeContinuousTestingMavenTestUtils was not fulfilled within 3 minutes. - org.awaitility.core.ConditionTimeoutException

org.awaitility.core.ConditionTimeoutException: Condition with Lambda expression in io.quarkus.maven.it.continuoustesting.TestModeContinuousTestingMavenTestUtils was not fulfilled within 3 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:1006)
	at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:975)
	at io.quarkus.maven.it.continuoustesting.TestModeContinuousTestingMavenTestUtils.waitForNextCompletion(TestModeContinuousTestingMavenTestUtils.java:49)
	at io.quarkus.maven.it.LaunchMojoTestBase.testThatTheTestsAreReRunMultiModule(LaunchMojoTestBase.java:56)