atlassian / atlassian/openapi-request-validator
Migrate to networknt json-schema-validator 3.x (Jackson 3 API)
- 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
Assessment
This issue has not been assessed yet.