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:
- Prefer the
InputFormat.JSON text boundary, or converting nodes to Jackson 3?
- 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.
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 aNoSuchMethodErrorwhen 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:
InputFormat.JSONentry points instead of Jackson-2 nodes, leaving the transformer pipeline and the 3.0/3.1 dialect split intact.Formatvalidators to Jackson 3 nodes (networknt'sFormat.matches(...)now hands them in).One behavior change worth confirming: a value beyond
Double.MAX_VALUEis now rejected by networknt as a type error ("number expected") rather than reaching the customdouble-format validator — still rejected, different error key.Questions before I open a PR:
InputFormat.JSONtext boundary, or converting nodes to Jackson 3?format.double→typechange on out-of-range values acceptable?Raising here first per CONTRIBUTING; I'll sign the Atlassian CLA before submitting.