Jetty 10+：如何让WebApp类对lib/ext下Jar可见及调用addServerClasses

一、上下文 XML 中调用 addServerClasses 的正确写法 #

Jetty 10 中addServerClasses改为静态方法，需传入Server实例。在 WebApp 上下文 XML 中，可通过当前WebAppContext的getServer()方法获取关联的Server对象，再调用该静态方法。示例配置如下：

<Configure class="org.eclipse.jetty.webapp.WebAppContext">
  <!-- 调用静态方法 addServerClasses，传入当前 Server 实例和类路径规则 -->
  <Call static="true" name="addServerClasses">
    <!-- 通过<Get>获取当前WebAppContext绑定的Server实例 -->
    <Arg><Get name="server" /></Arg>
    <!-- 负向规则：让Server类加载器放弃加载该包下的类，交由WebApp类加载器处理 -->
    <Arg>-com.corp.common.</Arg>
  </Call>
</Configure>

• static="true"：标记调用的是静态方法
• <Get name="server"/>：获取当前WebAppContext所属的Server实例，作为第一个参数传入
• -com.corp.common.：负向类加载规则，表示Server类加载器不再优先加载该包下的类，转而由WebApp类加载器加载，这样位于lib/ext的SPI实现（由Server类加载器加载）就能找到WebApp中的接口类。

二、解决思路的合理性评估 #

这个思路是可行且符合Jetty类加载设计逻辑的：

1. Jetty的类加载隔离机制中，lib/ext下的Jar由Server类加载器加载，而WebApp的WAR由独立的WebAppClassLoader加载，两者默认无法互相访问类。
2. 负向addServerClasses规则的作用是调整类加载优先级，让指定包的类由WebApp类加载器优先加载，这样Server类加载器加载的SPI实现就能访问到WebApp中的接口类，解决NoClassDefFoundError问题。

但需注意潜在风险：如果lib/ext中存在其他Jar包含com.corp.common包下的类，可能会引发类版本冲突，需确保该包下的类仅由WebApp提供。

三、替代方案参考 #

如果不想打破类加载隔离，可考虑：

• 将接口类打包到独立Jar，放入Jetty/lib/ext目录，让WebApp和SPI实现都通过Server类加载器加载该接口。此方式需统一维护接口版本，灵活性稍差。
• 避免使用SPI，改为通过WebApp提供的服务注册API让用户实现类主动注册，但需要修改WebApp的扩展逻辑。

内容的提问来源于stack exchange，提问作者Scott Ellis