atlassian / atlassian/openapi-request-validator

Migrate to networknt json-schema-validator 3.x (Jackson 3 API)

Open
#21 7 comments 5 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
14
Forks
5
PR merge metrics
No merged PRs in 30d

Description

networknt json-schema-validator 3.x moved its public API from Jackson 2 (`com.fasterxml.jackson.databind`) to Jackson 3 (`tools.jackson.databind`) and removed the Jackson-2 node overloads (`SchemaRegistry.getSchema(JsonNode)`, `Schema.validate(JsonNode)`). This library builds against 2.0.1 and calls those overloads, so any consumer that puts networknt 3.x on the classpath gets a `NoSuchMethodError` when the first schema is compiled.

A property bump alone won't do it: swagger-parser produces Jackson 2 nodes while networknt 3.x consumes Jackson 3, so there's a boundary to bridge — without touching the `com.atlassian.oai.validator.*` public API.

Proposed approach:
- Feed networknt JSON text through its `InputFormat.JSON` entry points instead of Jackson-2 nodes, leaving the transformer pipeline and the 3.0/3.1 dialect split intact.
- Move the custom `Format` validators to Jackson 3 nodes (networknt's `Format.matches(...)` now hands them in).
- Pin the Jackson 3 BOM to match what networknt depends on.

One behavior change worth confirming: a value beyond `Double.MAX_VALUE` is now rejected by networknt as a type error ("number expected") rather than reaching the custom `double`-format validator — still rejected, different error key.

Questions before I open a PR:
1. Prefer the `InputFormat.JSON` text boundary, or converting nodes to Jackson 3?
2. Is the `format.double` → `type` change on out-of-range values acceptable?

Raising here first per CONTRIBUTING; I'll sign the Atlassian CLA before submitting.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.