Build against networknt json-schema-validator 3.x - #24
Conversation
networknt 3.x replaced its Jackson 2 node API with Jackson 3 and removed the
getSchema/validate(JsonNode) overloads this library called, so consumers that
put networknt 3.x on the classpath hit NoSuchMethodError when the first schema
is compiled. Feed networknt JSON text via its InputFormat.JSON entry points,
move the custom Format validators to Jackson 3 nodes, and pin the Jackson 3 BOM
to the version networknt depends on. The public API is unchanged.
One behaviour change: a value beyond Double.MAX_VALUE is now rejected as a type
error ("number expected") rather than reaching the custom double-format
validator. The value is still rejected.
Refs atlassian#21
|
Hooray! All contributors have signed the CLA. |
|
LGTM. Thanks for the contribution! We had a go at this in the v3 branch, but this is a really nice solution. FYI I no longer work for Atlassian (as of a month ago) so I can't approve the PR. @agustafson-atl might be able to help get this over the line. |
Got it, thanks for spending time on this anyway. 🙇🏻 |
|
Hey guys how does it look here? Based on contribution graph it looks like you @jfnavin were maintaining this library almost single-handedly for the past years (thank you for all your work!), do you know if we can expect some continuity from Atlassian in this library or if the safest bet is to fork our own version if we want to proceed with this fix? Thanks. |
|
Maybe worth giving a gentle to @agustafson-atl on this. 🙂 |
3 participants
Consumers that put networknt json-schema-validator 3.x on the classpath alongside this library hit a
NoSuchMethodErrorthe first time a schema is compiled: 3.x replaced its Jackson 2 node API with Jackson 3 and removed thegetSchema/validate(JsonNode)overloads this library calls. This builds the library against networknt 3.x so the two stay compatible.swagger-parser still produces Jackson 2 nodes while networknt 3.x consumes Jackson 3, so the schema and the instance are handed to networknt as JSON text through its
InputFormat.JSONentry points; the customFormatvalidators move to Jackson 3 nodes. The transformer pipeline, the 3.0/3.1 dialect split, and thecom.atlassian.oai.validator.*public API are unchanged.One behaviour change: a value beyond
Double.MAX_VALUEis now rejected as a type error ("number expected") rather than reaching the customdouble-format validator. The value is still rejected; only the error key differs.Opening as a draft pending the two questions in #21 (text boundary vs. node conversion; whether the
format.double→typechange is acceptable), and before the Atlassian CLA is signed.Closes #21