Migrate to networknt json-schema-validator 3.x (Jackson 3 API)
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 45/100
- Issue 类型
- 重构
- 描述清晰度
- 基本清楚
- 活跃度
- 冷清
- 技术栈
- java
调研方向
从 SchemaRegistry.getSchema(JsonNode) 和 Schema.validate(JsonNode) 调用开始，然后跟踪 transformer 管道和自定义 Format 验证器。将 InputFormat.JSON 入口与 3.0/3.1 方言拆分进行比较，并固定 Jackson 3 BOM。完成的标准是库能够使用 networknt 3.x 构建，com.atlassian.oai.validator.* API 保持不变，并确认超出范围的数字行为。
由索引模型根据 Issue 内容生成。
描述
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.JSONentry points instead of Jackson-2 nodes, leaving the transformer pipeline and the 3.0/3.1 dialect split intact. - Move the custom
Formatvalidators to Jackson 3 nodes (networknt'sFormat.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.JSONtext boundary, or converting nodes to Jackson 3? - Is the
format.double→typechange on out-of-range values acceptable?
Raising here first per CONTRIBUTING; I'll sign the Atlassian CLA before submitting.
- 主要语言
- Java
- 星标
- 17
- 派生
- 6
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
atlassian/openapi-request-validator 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
-
难度 3/5 1-2 天 新手友好度 64/100
-
难度 3/5 半天 新手友好度 55/100
-
难度 3/5 1-2 天 新手友好度 62/100
-
难度 4/5 3-5 天 新手友好度 48/100
查看 atlassian/openapi-request-validator 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 86/100
hiero-ledger/hiero-sdk-java#3010 ·
维护者通常 1 天内回复
-
Optimize consumer version heatmap aggregation to avoid repeated scans可能已有人在做 @praykaria31 今天认领。 未关闭type/enhancement
难度 2/5 1-3 小时 新手友好度 72/100
Apicurio/apicurio-registry#10662 · 1 条评论 ·
维护者通常 1 天内回复
-
a:false-positive
难度 2/5 1-3 小时 新手友好度 77/100
维护者通常 1 天内回复
-
status: waiting-for-triage
难度 2/5 1-3 小时 新手友好度 74/100
spring-projects/spring-boot#52347 ·
维护者通常 2 天内回复
-
bug untriaged
难度 2/5 1-3 小时 新手友好度 76/100
opensearch-project/opensearch-migrations#3480 ·
维护者通常 2 天内回复