后端Web框架【免费下载链接】dropwizardA damn simple library for building production-ready RESTful web services.项目地址https://gitcode.com/gh_mirrors/dr/dropwizard点击查看免费下载本篇技术指南聚焦 Dropwizard 5.0.x 的官方升级说明upgrade notes系统梳理从 4.0.x 升级到 5.0.x 时的全部破坏性变更与依赖跃迁Java 17 基线、Jakarta EE 10、Jetty 12 的Handler#handle新签名、虚拟线程执行模型的纠正以及 Jackson、Hibernate、Liquibase、Jersey 等核心组件的版本变化。读完后你将能够对照源码确认每一项变更在仓库中的落地位置并制定一份可执行的迁移清单。Java 17不可商量的新基线Dropwizard 5.0.x 最重要的前置条件来自 Jetty 12——它不再支持 Java 17 以下的版本。为避免版本冲突Dropwizard 将自身的 Java 基线同步调整为 Java 17要使用 Dropwizard 5.0.x必须升级到 Java 17 或更高版本。这一基线在构建配置中可以直接验证。dropwizard-parent/pom.xml 中明确声明了maven.compiler.release17/maven.compiler.release也就是说整个项目使用release 17编译。如果你的项目目前运行在 Java 8/11 上升级 Dropwizard 5.0.x 的第一步就是提升 JDK 并检查字节码兼容性。值得注意的一点是虽然基线是 Java 17但仓库中与虚拟线程相关的测试如 VirtualThreadsTest通过EnabledForJreRange(min JRE.JAVA_21)限定在 Java 21 环境执行这反映了虚拟线程特性对运行时版本的额外要求。依赖版本总览5.0.x 是一次大规模的依赖升级。官方升级说明给出的关键版本变化如下组件4.0.x 版本5.0.x 版本argparse4j0.8.x0.9.xCaffeine2.8.x3.2.xGuava31.x33.4.x-jreHibernate6.1.x6.6.xHibernate Validator7.x8.0.xJackson2.15.x2.20.xJersey3.0.x3.1.xJetty11.x12.1.xJUnit5.9.x5.13.xLiquibase4.20.x4.33.xLogback1.4.x1.5.xSLF4J2.0.x2.0.17全部 Jakarta EE API9.x10.x这些声明性版本范围在 dropwizard-dependencies/pom.xml 中可以得到逐项印证当前分支为 5.0.3-SNAPSHOT具体小版本可能已随维护更新Jettyjetty.version12.1.11/jetty.versionpom.xml#L54Jacksonjackson.version2.22.2/jackson.version通过jackson-bom导入pom.xml#L87-L94Hibernatehibernate-core.version6.6.57.Final/hibernate-core.versionJerseyjersey.version3.1.12/jersey.version经jersey-bom导入Liquibaseliquibase-core.version4.33.0/liquibase-core.versionLogbacklogback.version1.5.38/logback.versionSLF4J 为2.0.19JUnitjunit5.version5.14.4/junit5.version经junit-bom导入对应用方的实际含义是如果你的工程独立管理了这些第三方依赖的版本需要逐一与上述 BOM 对齐否则很容易在运行期出现 API 缺失或类型不兼容。Jakarta EE 10 兼容性Dropwizard 4.0.x 完成了从javax命名空间到jakarta命名空间的迁移详见 4.0.x 升级说明而 5.0.x 将全部 Jakarta EE 依赖推进到 Jakarta EE 10 基线各 API 规格版本以 Jakarta EE 10 产品需求定义为准。在依赖清单中可以看到 Jakarta 10 基线对应的具体 API 版本dropwizard-dependencies/pom.xml#L41-L47jakarta.servlet-api6.0.0jakarta.ws.rs-api3.1.0JAX-RS 3.1jakarta.persistence-api3.1.0jakarta.validation-api3.0.2jakarta.annotation-api2.1.1、jakarta.el-api5.0.1、jakarta.inject-api2.0.1对已经迁移过 4.0.x 的 4.x 用户来说命名空间不再变化依旧是jakarta.*主要工作量在于上述 API 小版本升级带来的行为差异与第三方库兼容性检查。虚拟线程从反模式到 AdaptiveExecutionStrategy3.x 与 4.x 曾为虚拟线程提供基础支持但当时的实现是直接用虚拟线程承载 Jetty 的内部线程池——这在 Jetty 的线程模型中属于反模式线程池应当复用少量平台线程而虚拟线程的价值在于任务级并发。Dropwizard 5.x 纠正了这一行为Jetty 的线程池现在由平台线程承担虚拟线程以executor的形式提供给 Jetty 12 的AdaptiveExecutionStrategy由它在需要时调度任务执行到虚拟线程上。这一设计与仓库中的测试完全对应。VirtualThreadsTest 通过构造ExecutionStrategy.Producer并把它交给AdaptiveExecutionStrategy(producer, threadPool)实际派发一个任务再用VirtualThreads.isVirtualThread()探测任务是否运行在虚拟线程上分别验证setEnableVirtualThreads(true/false)与setEnableAdminVirtualThreads(true/false)四种组合的行为。这些开关定义在 DefaultServerFactory 中即你熟悉的server.applicationConnectors[].type: virtual-thread一类的配置项。此外LifecycleEnvironment 还会在启用虚拟线程时通过反射创建Executors.newVirtualThreadPerTaskExecutor()并注册为受管资源保证应用级异步执行器与 Jetty 侧的虚拟线程开关保持一致。Jetty 12 核心变更Jetty 12 对内核做了大量重构是本次升级中影响面最广的部分需要重点理解。servlet 组件模块化与 jetty-ee10-bom从 Jetty 12 起servlet 组件不再属于 Jetty 内核而是通过独立模块引入从而允许同一个 Jetty 版本搭配不同的 servlet API 版本。Dropwizard 负责管理与其兼容的 EE 组件5.0.x 通过导入jetty-ee10-bom来锁定 EE10 组件其中关键是jetty-ee10-servlet工件。这在 dropwizard-dependencies/pom.xml#L309-L315 中可以看到dependency groupIdorg.eclipse.jetty.ee10/groupId artifactIdjetty-ee10-bom/artifactId version${jetty.version}/version typepom/type scopeimport/scope /dependency同时dropwizard-jetty/pom.xml 等模块显式依赖了jetty-ee10-servlet保证各模块引用的是同一版本族。Handler#handle 方法签名变更Jetty 12 最核心的 API 变化是Handler#handle(...)的签名重写从旧式的void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException变为boolean handle(Request request, Response response, Callback callback) throws Exception两个语义变化需要牢记“已处理”状态不再通过request.setHandled(boolean)设置而是由handle方法的返回值表达新增的Callback对象要求当且仅当请求由该 Handler 处理时必须将其 complete 或 abort。如果你在项目中自定义了 JettyHandler例如自定义请求过滤链、健康探针前置处理这段代码在 5.0.x 下必然无法编译需要按新签名重写。GZIP 错误状态码500 改 400Jetty 在收到非法 GZIP 字节时默认返回 500。Dropwizard 的职责是区分“客户端错误”与“服务端错误”因此捕获这类异常并改写为 400。由于 GZIP 处理发生在 Jetty Handler 层而非 servlet 层5.0.x 的实现需要同时覆盖 servlet 与非 servlet 场景相关类集中在 dropwizard-jetty 模块ZipExceptionHandlingGzipHandlerHandler 层捕获ZipException/EOFException由 GzipHandlerFactory 按server.gzipHandler配置挂入 Handler 链ZipExceptionHandlingRequestWrapper记录读取输入流时发生的 GZIP 异常ZipExceptionHandlingServletFilterservlet 环境下的过滤器当请求为 JettyServletApiRequest且包装器中记录了 GZIP 异常时抛出携带HttpStatus.BAD_REQUEST_400的BadMessageException。迁移要点如果你在 4.x 中曾手动注册过ZipExceptionHandlingGzipHandler升级到 5.0.x 后建议同时注册ZipExceptionHandlingServletFilter以在 servlet 环境中重新启用 500→400 的状态码改写。测试用例 GzipServletHandlerTest 验证了这条 Handler Filter 组合的工作路径。新增 unix-socket 连接器5.0.x 新增类型为unix-socket的连接器仓库中对应独立的 dropwizard-unix-socket 模块。具体的配置参数如socketPath等请参阅配置指南中 unix sockets 一节。典型用途是通过反向代理如 nginx、Caddy以 unix domain socket 承接本地流量减少 TCP 栈开销。移除 Server Push 支持Jetty 早已对PushCacheFilter弃用其承载的 HTTP 特性本身已被弃用Jetty 12 最终移除了 server push 能力。因此 Dropwizard 5.0.x 一并删除了该特性的配置类。如果你的 4.x 配置中使用了server.pushCacheFilters升级时须删除该配置段并在构建日志中确认相关类引用已被清理。移除 server.maxQueuedRequests配置项server.maxQueuedRequests在 5.0.x 中被移除且没有替代项。这与 Jetty 12 的线程架构演进一致——旧版本中请求队列长度可显式控制而新架构下该维度由 Jetty 12 的线程池与执行策略自行管理可参考 Jetty 12 官方文档中 Threading Architecture 一节的说明。迁移时只需从 YAML 配置中删除该键即可无需寻找等价配置。Jackson 2.20.xJackson 从 2.15.x 升级到 2.20.x当前分支 BOM 中实际锁定为 2.22.2见 dropwizard-dependencies/pom.xml#L40属于跨度显著的升级包含性能优化、对 Java 17 特性的增强以及 databind/core/annotations 各模块的持续更新。官方判断是多数应用不需要修改代码但自定义序列化器/反序列化器建议重点复查尤其是依赖了内部 API 或旧版本特有行为的实现。JUnit 5.13.xJUnit 从 5.9.x 升级到 5.13.x当前分支 BOM 锁定为 5.14.4带来与现代 Java 版本更好的集成、更强的并行测试执行能力和更新的 Jupiter API 与测试引擎。需要注意如果你的测试仍在使用 JUnit 4 API请确保已完成向 JUnit 5 的迁移或引入了合适的兼容依赖如 vintage 引擎。Dropwizard 自身的测试基座dropwizard-testing模块也已基于 JUnit 5 的 Jupiter API 编写。Hibernate 6.6.xHibernate 从 6.1.x 升级到 6.6.x当前分支 BOM 锁定为 6.6.57.Final亮点包括类型系统的持续改进、性能增强、缺陷修复以及更强的 Jakarta Persistence 3.1 支持对应 dropwizard-dependencies/pom.xml#L44 中的jakarta.persistence-api3.1.0。对使用 DropwizardHibernateBundle封装的应用大部分变化应是透明的但如果你直接使用了 Hibernate 原生 API需要对照 Hibernate 6.6 官方迁移指南检查 6.1 → 6.6 之间的变更。4.0.x 阶段 Hibernate 5 → 6 的变更点Criteria移除、Serializable键限制移除、USE_NEW_ID_GENERATOR_MAPPINGS移除见 4.0.x 升级说明在此版本上不再适用但仍值得作为历史背景了解。Liquibase 4.33.xLiquibase 从 4.20.x 升级到 4.33.xBOM 锁定 4.33.0涵盖 changelog 解析与校验增强、数据库支持改进和性能优化。迁移时建议检查 changelog 文件XML/YAML/SQL中是否使用了已废弃的特性并参考 Liquibase 官方 release notes 了解 4.20 → 4.33 的细节。相关配置入口见 迁移指南。Jersey 3.1.x 与 HK2 Binder 语义变化Jersey 从 3.0.x 升级到 3.1.xBOM 锁定 3.1.12。一个需要留意的语义变化是Jersey 3.1 将 HK2 binder 视为 provider。这改变了 binder 在 Jersey 与 HK2 中的处理语义——如果你自定义过Binder例如向 HK2 容器注册额外服务其注册时机与生效方式可能不同升级后建议对依赖 HK2 注入的功能做一次回归验证。Dropwizard 的 Jersey 集成层dropwizard-jersey模块与 HK2 的锁定版本hk2.version3.0.6见 dropwizard-dependencies/pom.xml#L37已经适配了这一变化。请求日志logback-access 与 Jetty 12 的新协作历史上基于logback-access的请求日志一直存在一些特殊问题Dropwizard 为此提供了 workaround。Jetty 12 配套的新版logback-access实现提供了一个 request wrapper它只为部分“相关”方法从 JettyRequest构造HttpServletRequest这意味着日志模式里能取到的字段受限。Dropwizard 5.0.x 的对策是提供自定义 workaround通过解析 servlet 上下文直接使用当前活跃的HttpServletRequest进行请求日志记录从而支持HttpServletRequest的全部方法并在后续 servlet API 更新中保持更稳定的行为。实现位于 dropwizard-request-logging 模块其 BOM 中锁定的是logback-access-jetty12版本 2.0.15见 dropwizard-dependencies/pom.xml#L397-L401。如果你自定义过请求日志格式建议对照 e2e 中的 请求日志集成测试 验证各模式字段的行为。升级检查清单结合以上全部内容从 4.0.x 迁移到 5.0.x 的实操清单如下JDK 提升至 17确认maven.compiler.release/release与基线一致删除 YAML 中的server.maxQueuedRequests无替代项移除server.pushCacheFilters配置及相关代码引用如曾手动使用ZipExceptionHandlingGzipHandler补充注册ZipExceptionHandlingServletFilter自定义 JettyHandler的代码按boolean handle(Request, Response, Callback)新签名重写注意Callback的 complete/abort 语义依赖 HK2 binder 的自定义 provider 注册做回归测试Jersey 3.1 语义变化;复查自定义 Jackson 序列化器/反序列化器2.15 → 2.20直接调用 Hibernate 原生 API 的代码对照 6.6 迁移指南检查 Liquibase changelog 中的废弃特性使用虚拟线程时确认enableVirtualThreads/enableAdminVirtualThreads配置DefaultServerFactory理解其执行模型已从“虚拟线程池”变为“平台线程池 虚拟线程 executor”测试框架若含 JUnit 4 用例确认 JUnit 5 迁移或兼容依赖。完成上述步骤后5.0.x 的绝大部分升级对业务代码是透明的——真正的代码改动集中在 Jetty Handler 适配与配置项清理两处其余主要是依赖版本对齐与回归验证。赞分享后端Web框架【免费下载链接】dropwizardA damn simple library for building production-ready RESTful web services.项目地址https://gitcode.com/gh_mirrors/dr/dropwizard点击查看免费下载相关推荐Dropwizard 3.0.x 升级指南Java 11 迁移、Jetty 10、HttpClient 5 与包结构重构Dropwizard 3.0.x 升级指南Java 11 迁移、Jetty 10、HttpClient 5 与包结构重构 Dropwizard 3.0.x 是后端Web框架Dropwizard 4.0.x 升级指南Jakarta EE 命名空间迁移与 Hibernate 6 落地解析Dropwizard 4.0.x 升级指南Jakarta EE 命名空间迁移与 Hibernate 6 落地解析 Dropwizard 4.0.x 是项目历史后端Web框架Dropwizard 跨版本升级指南从 0.7.x 到 5.0.x 的完整迁移路线图Dropwizard 跨版本升级指南从 0.7.x 到 5.0.x 的完整迁移路线图 本指南以 Dropwizard 官方手册中的 Upgrade Notes后端Web框架上一篇Tack CI/CD集成如何将Kubernetes集群部署纳入持续交付流程下一篇8 条规则和 12 项自检把 AI 痕迹从稿子里清干净stop-slop 实用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dropwizard 5.0.x 升级指南：Java 17 基线、Jakarta EE 10 与 Jetty 12 全面升级
后端Web框架【免费下载链接】dropwizardA damn simple library for building production-ready RESTful web services.项目地址https://gitcode.com/gh_mirrors/dr/dropwizard点击查看免费下载本篇技术指南聚焦 Dropwizard 5.0.x 的官方升级说明upgrade notes系统梳理从 4.0.x 升级到 5.0.x 时的全部破坏性变更与依赖跃迁Java 17 基线、Jakarta EE 10、Jetty 12 的Handler#handle新签名、虚拟线程执行模型的纠正以及 Jackson、Hibernate、Liquibase、Jersey 等核心组件的版本变化。读完后你将能够对照源码确认每一项变更在仓库中的落地位置并制定一份可执行的迁移清单。Java 17不可商量的新基线Dropwizard 5.0.x 最重要的前置条件来自 Jetty 12——它不再支持 Java 17 以下的版本。为避免版本冲突Dropwizard 将自身的 Java 基线同步调整为 Java 17要使用 Dropwizard 5.0.x必须升级到 Java 17 或更高版本。这一基线在构建配置中可以直接验证。dropwizard-parent/pom.xml 中明确声明了maven.compiler.release17/maven.compiler.release也就是说整个项目使用release 17编译。如果你的项目目前运行在 Java 8/11 上升级 Dropwizard 5.0.x 的第一步就是提升 JDK 并检查字节码兼容性。值得注意的一点是虽然基线是 Java 17但仓库中与虚拟线程相关的测试如 VirtualThreadsTest通过EnabledForJreRange(min JRE.JAVA_21)限定在 Java 21 环境执行这反映了虚拟线程特性对运行时版本的额外要求。依赖版本总览5.0.x 是一次大规模的依赖升级。官方升级说明给出的关键版本变化如下组件4.0.x 版本5.0.x 版本argparse4j0.8.x0.9.xCaffeine2.8.x3.2.xGuava31.x33.4.x-jreHibernate6.1.x6.6.xHibernate Validator7.x8.0.xJackson2.15.x2.20.xJersey3.0.x3.1.xJetty11.x12.1.xJUnit5.9.x5.13.xLiquibase4.20.x4.33.xLogback1.4.x1.5.xSLF4J2.0.x2.0.17全部 Jakarta EE API9.x10.x这些声明性版本范围在 dropwizard-dependencies/pom.xml 中可以得到逐项印证当前分支为 5.0.3-SNAPSHOT具体小版本可能已随维护更新Jettyjetty.version12.1.11/jetty.versionpom.xml#L54Jacksonjackson.version2.22.2/jackson.version通过jackson-bom导入pom.xml#L87-L94Hibernatehibernate-core.version6.6.57.Final/hibernate-core.versionJerseyjersey.version3.1.12/jersey.version经jersey-bom导入Liquibaseliquibase-core.version4.33.0/liquibase-core.versionLogbacklogback.version1.5.38/logback.versionSLF4J 为2.0.19JUnitjunit5.version5.14.4/junit5.version经junit-bom导入对应用方的实际含义是如果你的工程独立管理了这些第三方依赖的版本需要逐一与上述 BOM 对齐否则很容易在运行期出现 API 缺失或类型不兼容。Jakarta EE 10 兼容性Dropwizard 4.0.x 完成了从javax命名空间到jakarta命名空间的迁移详见 4.0.x 升级说明而 5.0.x 将全部 Jakarta EE 依赖推进到 Jakarta EE 10 基线各 API 规格版本以 Jakarta EE 10 产品需求定义为准。在依赖清单中可以看到 Jakarta 10 基线对应的具体 API 版本dropwizard-dependencies/pom.xml#L41-L47jakarta.servlet-api6.0.0jakarta.ws.rs-api3.1.0JAX-RS 3.1jakarta.persistence-api3.1.0jakarta.validation-api3.0.2jakarta.annotation-api2.1.1、jakarta.el-api5.0.1、jakarta.inject-api2.0.1对已经迁移过 4.0.x 的 4.x 用户来说命名空间不再变化依旧是jakarta.*主要工作量在于上述 API 小版本升级带来的行为差异与第三方库兼容性检查。虚拟线程从反模式到 AdaptiveExecutionStrategy3.x 与 4.x 曾为虚拟线程提供基础支持但当时的实现是直接用虚拟线程承载 Jetty 的内部线程池——这在 Jetty 的线程模型中属于反模式线程池应当复用少量平台线程而虚拟线程的价值在于任务级并发。Dropwizard 5.x 纠正了这一行为Jetty 的线程池现在由平台线程承担虚拟线程以executor的形式提供给 Jetty 12 的AdaptiveExecutionStrategy由它在需要时调度任务执行到虚拟线程上。这一设计与仓库中的测试完全对应。VirtualThreadsTest 通过构造ExecutionStrategy.Producer并把它交给AdaptiveExecutionStrategy(producer, threadPool)实际派发一个任务再用VirtualThreads.isVirtualThread()探测任务是否运行在虚拟线程上分别验证setEnableVirtualThreads(true/false)与setEnableAdminVirtualThreads(true/false)四种组合的行为。这些开关定义在 DefaultServerFactory 中即你熟悉的server.applicationConnectors[].type: virtual-thread一类的配置项。此外LifecycleEnvironment 还会在启用虚拟线程时通过反射创建Executors.newVirtualThreadPerTaskExecutor()并注册为受管资源保证应用级异步执行器与 Jetty 侧的虚拟线程开关保持一致。Jetty 12 核心变更Jetty 12 对内核做了大量重构是本次升级中影响面最广的部分需要重点理解。servlet 组件模块化与 jetty-ee10-bom从 Jetty 12 起servlet 组件不再属于 Jetty 内核而是通过独立模块引入从而允许同一个 Jetty 版本搭配不同的 servlet API 版本。Dropwizard 负责管理与其兼容的 EE 组件5.0.x 通过导入jetty-ee10-bom来锁定 EE10 组件其中关键是jetty-ee10-servlet工件。这在 dropwizard-dependencies/pom.xml#L309-L315 中可以看到dependency groupIdorg.eclipse.jetty.ee10/groupId artifactIdjetty-ee10-bom/artifactId version${jetty.version}/version typepom/type scopeimport/scope /dependency同时dropwizard-jetty/pom.xml 等模块显式依赖了jetty-ee10-servlet保证各模块引用的是同一版本族。Handler#handle 方法签名变更Jetty 12 最核心的 API 变化是Handler#handle(...)的签名重写从旧式的void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException变为boolean handle(Request request, Response response, Callback callback) throws Exception两个语义变化需要牢记“已处理”状态不再通过request.setHandled(boolean)设置而是由handle方法的返回值表达新增的Callback对象要求当且仅当请求由该 Handler 处理时必须将其 complete 或 abort。如果你在项目中自定义了 JettyHandler例如自定义请求过滤链、健康探针前置处理这段代码在 5.0.x 下必然无法编译需要按新签名重写。GZIP 错误状态码500 改 400Jetty 在收到非法 GZIP 字节时默认返回 500。Dropwizard 的职责是区分“客户端错误”与“服务端错误”因此捕获这类异常并改写为 400。由于 GZIP 处理发生在 Jetty Handler 层而非 servlet 层5.0.x 的实现需要同时覆盖 servlet 与非 servlet 场景相关类集中在 dropwizard-jetty 模块ZipExceptionHandlingGzipHandlerHandler 层捕获ZipException/EOFException由 GzipHandlerFactory 按server.gzipHandler配置挂入 Handler 链ZipExceptionHandlingRequestWrapper记录读取输入流时发生的 GZIP 异常ZipExceptionHandlingServletFilterservlet 环境下的过滤器当请求为 JettyServletApiRequest且包装器中记录了 GZIP 异常时抛出携带HttpStatus.BAD_REQUEST_400的BadMessageException。迁移要点如果你在 4.x 中曾手动注册过ZipExceptionHandlingGzipHandler升级到 5.0.x 后建议同时注册ZipExceptionHandlingServletFilter以在 servlet 环境中重新启用 500→400 的状态码改写。测试用例 GzipServletHandlerTest 验证了这条 Handler Filter 组合的工作路径。新增 unix-socket 连接器5.0.x 新增类型为unix-socket的连接器仓库中对应独立的 dropwizard-unix-socket 模块。具体的配置参数如socketPath等请参阅配置指南中 unix sockets 一节。典型用途是通过反向代理如 nginx、Caddy以 unix domain socket 承接本地流量减少 TCP 栈开销。移除 Server Push 支持Jetty 早已对PushCacheFilter弃用其承载的 HTTP 特性本身已被弃用Jetty 12 最终移除了 server push 能力。因此 Dropwizard 5.0.x 一并删除了该特性的配置类。如果你的 4.x 配置中使用了server.pushCacheFilters升级时须删除该配置段并在构建日志中确认相关类引用已被清理。移除 server.maxQueuedRequests配置项server.maxQueuedRequests在 5.0.x 中被移除且没有替代项。这与 Jetty 12 的线程架构演进一致——旧版本中请求队列长度可显式控制而新架构下该维度由 Jetty 12 的线程池与执行策略自行管理可参考 Jetty 12 官方文档中 Threading Architecture 一节的说明。迁移时只需从 YAML 配置中删除该键即可无需寻找等价配置。Jackson 2.20.xJackson 从 2.15.x 升级到 2.20.x当前分支 BOM 中实际锁定为 2.22.2见 dropwizard-dependencies/pom.xml#L40属于跨度显著的升级包含性能优化、对 Java 17 特性的增强以及 databind/core/annotations 各模块的持续更新。官方判断是多数应用不需要修改代码但自定义序列化器/反序列化器建议重点复查尤其是依赖了内部 API 或旧版本特有行为的实现。JUnit 5.13.xJUnit 从 5.9.x 升级到 5.13.x当前分支 BOM 锁定为 5.14.4带来与现代 Java 版本更好的集成、更强的并行测试执行能力和更新的 Jupiter API 与测试引擎。需要注意如果你的测试仍在使用 JUnit 4 API请确保已完成向 JUnit 5 的迁移或引入了合适的兼容依赖如 vintage 引擎。Dropwizard 自身的测试基座dropwizard-testing模块也已基于 JUnit 5 的 Jupiter API 编写。Hibernate 6.6.xHibernate 从 6.1.x 升级到 6.6.x当前分支 BOM 锁定为 6.6.57.Final亮点包括类型系统的持续改进、性能增强、缺陷修复以及更强的 Jakarta Persistence 3.1 支持对应 dropwizard-dependencies/pom.xml#L44 中的jakarta.persistence-api3.1.0。对使用 DropwizardHibernateBundle封装的应用大部分变化应是透明的但如果你直接使用了 Hibernate 原生 API需要对照 Hibernate 6.6 官方迁移指南检查 6.1 → 6.6 之间的变更。4.0.x 阶段 Hibernate 5 → 6 的变更点Criteria移除、Serializable键限制移除、USE_NEW_ID_GENERATOR_MAPPINGS移除见 4.0.x 升级说明在此版本上不再适用但仍值得作为历史背景了解。Liquibase 4.33.xLiquibase 从 4.20.x 升级到 4.33.xBOM 锁定 4.33.0涵盖 changelog 解析与校验增强、数据库支持改进和性能优化。迁移时建议检查 changelog 文件XML/YAML/SQL中是否使用了已废弃的特性并参考 Liquibase 官方 release notes 了解 4.20 → 4.33 的细节。相关配置入口见 迁移指南。Jersey 3.1.x 与 HK2 Binder 语义变化Jersey 从 3.0.x 升级到 3.1.xBOM 锁定 3.1.12。一个需要留意的语义变化是Jersey 3.1 将 HK2 binder 视为 provider。这改变了 binder 在 Jersey 与 HK2 中的处理语义——如果你自定义过Binder例如向 HK2 容器注册额外服务其注册时机与生效方式可能不同升级后建议对依赖 HK2 注入的功能做一次回归验证。Dropwizard 的 Jersey 集成层dropwizard-jersey模块与 HK2 的锁定版本hk2.version3.0.6见 dropwizard-dependencies/pom.xml#L37已经适配了这一变化。请求日志logback-access 与 Jetty 12 的新协作历史上基于logback-access的请求日志一直存在一些特殊问题Dropwizard 为此提供了 workaround。Jetty 12 配套的新版logback-access实现提供了一个 request wrapper它只为部分“相关”方法从 JettyRequest构造HttpServletRequest这意味着日志模式里能取到的字段受限。Dropwizard 5.0.x 的对策是提供自定义 workaround通过解析 servlet 上下文直接使用当前活跃的HttpServletRequest进行请求日志记录从而支持HttpServletRequest的全部方法并在后续 servlet API 更新中保持更稳定的行为。实现位于 dropwizard-request-logging 模块其 BOM 中锁定的是logback-access-jetty12版本 2.0.15见 dropwizard-dependencies/pom.xml#L397-L401。如果你自定义过请求日志格式建议对照 e2e 中的 请求日志集成测试 验证各模式字段的行为。升级检查清单结合以上全部内容从 4.0.x 迁移到 5.0.x 的实操清单如下JDK 提升至 17确认maven.compiler.release/release与基线一致删除 YAML 中的server.maxQueuedRequests无替代项移除server.pushCacheFilters配置及相关代码引用如曾手动使用ZipExceptionHandlingGzipHandler补充注册ZipExceptionHandlingServletFilter自定义 JettyHandler的代码按boolean handle(Request, Response, Callback)新签名重写注意Callback的 complete/abort 语义依赖 HK2 binder 的自定义 provider 注册做回归测试Jersey 3.1 语义变化;复查自定义 Jackson 序列化器/反序列化器2.15 → 2.20直接调用 Hibernate 原生 API 的代码对照 6.6 迁移指南检查 Liquibase changelog 中的废弃特性使用虚拟线程时确认enableVirtualThreads/enableAdminVirtualThreads配置DefaultServerFactory理解其执行模型已从“虚拟线程池”变为“平台线程池 虚拟线程 executor”测试框架若含 JUnit 4 用例确认 JUnit 5 迁移或兼容依赖。完成上述步骤后5.0.x 的绝大部分升级对业务代码是透明的——真正的代码改动集中在 Jetty Handler 适配与配置项清理两处其余主要是依赖版本对齐与回归验证。赞分享后端Web框架【免费下载链接】dropwizardA damn simple library for building production-ready RESTful web services.项目地址https://gitcode.com/gh_mirrors/dr/dropwizard点击查看免费下载相关推荐Dropwizard 3.0.x 升级指南Java 11 迁移、Jetty 10、HttpClient 5 与包结构重构Dropwizard 3.0.x 升级指南Java 11 迁移、Jetty 10、HttpClient 5 与包结构重构 Dropwizard 3.0.x 是后端Web框架Dropwizard 4.0.x 升级指南Jakarta EE 命名空间迁移与 Hibernate 6 落地解析Dropwizard 4.0.x 升级指南Jakarta EE 命名空间迁移与 Hibernate 6 落地解析 Dropwizard 4.0.x 是项目历史后端Web框架Dropwizard 跨版本升级指南从 0.7.x 到 5.0.x 的完整迁移路线图Dropwizard 跨版本升级指南从 0.7.x 到 5.0.x 的完整迁移路线图 本指南以 Dropwizard 官方手册中的 Upgrade Notes后端Web框架上一篇Tack CI/CD集成如何将Kubernetes集群部署纳入持续交付流程下一篇8 条规则和 12 项自检把 AI 痕迹从稿子里清干净stop-slop 实用指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考