Migrate to Jackson 3.x APIs

[reta]

Description

Migrate to Jackson 3.x APIs. The OpenSearch Core will stop bundling Jackson 2.x (planned for 3.9.0), and it does not prevent plugins from using Jackson 2.x if needed, however all plugins have been migrated to Jackson 3.x APIs.

Related Issues

Part of opensearch-project/OpenSearch#22197, fixes the migration gap after #5361

Check List

• New functionality includes testing.
• New functionality has been documented.
• New functionality has javadoc added.
• New functionality has a user manual doc added.
• New PPL command checklist all confirmed.
• API changes companion pull request created.
• Commits are signed per the DCO using --signoff or -s.
• Public documentation issue/PR created.

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.

[github-actions]

PR Code Analyzer ❗

AI-powered 'Code-Diff-Analyzer' found issues on commit 3d4ffb1.

Path	Line	Severity	Description
core/build.gradle	56	high	Three Jackson dependencies migrated from 'com.fasterxml.jackson' group to 'tools.jackson' group (jackson-core, jackson-databind, jackson-dataformat-yaml). Namespace change from an established artifact to a different group ID must be verified against official Jackson 3.x release artifacts.
opensearch/build.gradle	38	high	Three Jackson dependencies migrated from 'com.fasterxml.jackson.core/dataformat' to 'tools.jackson.core/dataformat' group (jackson-core, jackson-databind, jackson-dataformat-cbor). Supply chain risk: artifact authenticity cannot be confirmed without maintainer verification.
plugin/build.gradle	158	high	Two Jackson core dependencies (jackson-core, jackson-databind) migrated from 'com.fasterxml.jackson.core' to 'tools.jackson.core' group. Dependency group namespace change must be verified against official artifact registries.
prometheus/build.gradle	25	high	Three Jackson dependencies migrated from 'com.fasterxml.jackson' to 'tools.jackson' group (jackson-core, jackson-databind, jackson-dataformat-cbor). Namespace change requires maintainer verification of artifact provenance.
protocol/build.gradle	34	high	Three Jackson dependencies plus a resolutionStrategy.force directive migrated from 'com.fasterxml.jackson' to 'tools.jackson' group. The forced resolution override for the new namespace amplifies supply chain risk if the artifact is not legitimate.

The table above displays the top 10 most important findings.

Total: 5 | Critical: 0 | High: 5 | Medium: 0 | Low: 0

---

Pull Requests Author(s): Please update your Pull Request according to the report above.

Repository Maintainer(s): You can bypass diff analyzer by adding label skip-diff-analyzer after reviewing the changes carefully, then re-run failed actions. To re-enable the analyzer, remove the label, then re-run all actions.

---

⚠️ Note: The Code-Diff-Analyzer helps protect against potentially harmful code patterns. Please ensure you have thoroughly reviewed the changes beforehand.

Thanks.

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🧪 No relevant tests

🔒 No security concerns identified

✅ No TODO sections

🔀 No multiple PR themes

⚡ Recommended focus areas for review Possible Issue The JsonFactory constructor call changed from JSON_FACTORY.createParser(jsonStr) to JSON_FACTORY.createParser(ObjectReadContext.empty(), jsonStr). If JSON_FACTORY is not initialized with the correct context or if ObjectReadContext.empty() does not provide the necessary configuration, this could cause parsing failures or unexpected behavior when processing JSON strings. try (JsonParser parser = JSON_FACTORY.createParser(ObjectReadContext.empty(), jsonStr)) { Possible Issue Changed from jsonNode.fields() to jsonNode.properties().iterator(). If the Jackson 3.x properties() method returns a different structure or behaves differently than Jackson 2.x fields(), this could break JSON object iteration and cause incorrect data processing or runtime errors. for (var iter = jsonNode.properties().iterator(); iter.hasNext(); ) { Possible Issue Changed from jsonNode.asText() to jsonNode.asString(). If asString() in Jackson 3.x has different null-handling or type-coercion behavior than asText() in Jackson 2.x, this could cause unexpected null values or type conversion errors when processing JSON string nodes. return new ExprStringValue(jsonNode.asString());

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Combine property inclusion configurations Calling changeDefaultPropertyInclusion() twice may cause the first configuration to be overwritten by the second. Combine both value and content inclusion settings in a single call to ensure both configurations are applied correctly. core/src/main/java/org/opensearch/sql/utils/YamlFormatter.java [32-38] YAML_MAPPER = YAMLMapper.builder(builder.build()) .changeDefaultPropertyInclusion( - incl -> incl.withValueInclusion(JsonInclude.Include.NON_NULL)) - .changeDefaultPropertyInclusion( - incl -> incl.withContentInclusion(JsonInclude.Include.NON_NULL)) + incl -> incl.withValueInclusion(JsonInclude.Include.NON_NULL) + .withContentInclusion(JsonInclude.Include.NON_NULL)) .build(); Suggestion importance[1-10]: 8 __ Why: This identifies a potential bug where calling changeDefaultPropertyInclusion() twice may cause the first configuration to be overwritten. Combining both settings in a single call ensures both withValueInclusion and withContentInclusion are applied correctly.	Medium
General	Verify properties iteration behavior The migration from fields() to properties().iterator() changes the iteration behavior. Verify that properties() returns the expected entries and maintains the same ordering as the previous fields() method to prevent data processing issues. core/src/main/java/org/opensearch/sql/utils/JsonUtils.java [93-96] +// Verify properties() maintains same behavior as fields() for (var iter = jsonNode.properties().iterator(); iter.hasNext(); ) { Map.Entry<String, JsonNode> entry = iter.next(); values.put(entry.getKey(), processJsonNode(entry.getValue())); } Suggestion importance[1-10]: 6 __ Why: The migration from fields() to properties().iterator() is a significant API change that warrants verification. While likely correct, confirming that ordering and behavior remain consistent is important for data processing correctness.	Low
	Verify ObjectReadContext configuration The ObjectReadContext.empty() may not provide necessary configuration for parsing. Consider using a properly configured ObjectReadContext with appropriate settings for the JSON parsing requirements, or verify that an empty context is sufficient for all use cases. core/src/main/java/org/opensearch/sql/expression/function/jsonUDF/JsonExtractAllFunctionImpl.java [110] try (JsonParser parser = JSON_FACTORY.createParser(ObjectReadContext.empty(), jsonString)) { JsonToken token; - + // Verify ObjectReadContext.empty() provides required parsing configuration while ((token = parser.nextToken()) != null) { switch (token) { Suggestion importance[1-10]: 5 __ Why: The suggestion to verify ObjectReadContext.empty() is valid but represents a precautionary check rather than a critical issue. The migration appears intentional and likely tested, making this a moderate-priority verification task.	Low
	Verify propertyNames forEach compatibility The migration from fieldNames().forEachRemaining() to propertyNames().forEach() changes the iteration mechanism. Verify that propertyNames() returns an Iterable or Stream that supports forEach() and maintains the same iteration order to prevent potential runtime errors. opensearch/src/main/java/org/opensearch/sql/opensearch/data/utils/OpenSearchJsonContent.java [78-80] +// Verify propertyNames() returns compatible type for forEach mapValue .propertyNames() .forEach(field -> map.put(field, new OpenSearchJsonContent(mapValue.get(field)))); Suggestion importance[1-10]: 5 __ Why: The migration from fieldNames().forEachRemaining() to propertyNames().forEach() changes the iteration mechanism. While likely correct, verifying API compatibility and iteration order is a reasonable precautionary measure.	Low