Jetty项目从11.0.24升级到12.0.14的核心变更解析

架构设计的重大变革

Jetty 12版本带来了架构层面的重大调整，最核心的变化是将底层核心API与Servlet规范API进行了彻底分离。这种解耦设计使得Jetty能够更灵活地支持不同版本的Servlet规范，同时也带来了开发者使用方式上的显著变化。

在Jetty 11及之前版本中，核心功能与Servlet API是紧密耦合的，开发者可以直接通过Jetty提供的扩展接口修改请求参数、内容类型等属性。而在Jetty 12中，这种设计哲学发生了根本性转变，请求对象(Request)被设计为不可变对象，所有修改操作都需要通过包装器模式来实现。

安全认证模块的重构

Jetty 12对安全认证模块进行了全面重构，主要体现在以下几个方面：

1. 用户身份标识类：原先的DefaultUserIdentity类已被重构为内部实现，现在位于org.eclipse.jetty.security.internal包下。开发者应当避免直接使用标记为"internal"的包，这些类不是公开API的一部分。

2. 认证状态管理：原有的UserAuthentication类被UserAuthenticationSucceeded替代，认证状态管理则通过AuthenticationState枚举来实现。值得注意的是，原先的UNAUTHENTICATED状态在新的认证体系中需要通过不同的方式来处理。

3. 会话管理：会话相关类从org.eclipse.jetty.server.session包迁移到了org.eclipse.jetty.server包下，类名简化为Session，这反映了Jetty对核心概念的简化。

请求处理的不可变设计

Jetty 12中请求对象(Request)采用了不可变设计模式，这带来了使用方式上的重大变化：

1. 请求属性修改：所有原先直接修改请求属性的方法(如setContentParameters、setContentType、setMethod等)都不再可用。开发者需要通过包装器模式来实现类似功能。

2. 请求包装实现：开发者需要创建自定义的Request.Wrapper子类来修改请求行为。典型的实现包括：

   • 重写getMethod()方法来实现HTTP方法的修改
   • 通过构建新的HttpFields实例来修改请求头
   • 使用FormFields.set()方法来设置表单参数

3. 会话处理：获取会话处理器的方式变得更加明确，需要通过Servlet上下文来获取，这体现了更清晰的层次结构。

迁移实践建议

对于需要从Jetty 11迁移到Jetty 12的项目，建议采取以下策略：

1. 评估依赖程度：首先评估项目对Jetty扩展API的依赖程度，确定是否需要完全基于核心API重构，还是可以迁移到Servlet标准API。

2. 逐步替换：对于安全认证相关的代码，建议逐步替换为新的认证API，特别注意处理认证状态的变化。

3. 请求处理重构：对于需要修改请求属性的场景，统一改为使用包装器模式，这虽然增加了代码量，但带来了更好的线程安全性和可维护性。

4. 会话管理：更新会话相关的导入路径，并适应新的会话获取方式。

Jetty 12的这些架构改进虽然带来了短期内的迁移成本，但从长远来看，这种清晰的层次分离和不可变设计将为应用带来更好的稳定性和可维护性，特别是在需要支持多版本Servlet规范或进行定制化开发的场景下。