升级Tomcat至9.0.43后Win服务重启报WsFilter缺destroy()错误如何处理

首先需要明确：该报错本质并非Tomcat 9.0.43官方发行包中tomcat-websocket.jar内置的WsFilter类本身缺失destroy方法实现——官方发行包里该类完整实现了javax.servlet.Filter接口的所有抽象方法，出现这个问题的核心原因是类加载冲突，运行时错误加载了不匹配版本的WsFilter类。你感知到的“当前lib下的jar中缺少destroy方法”，本质是类加载器优先加载了应用目录、其他自定义类路径中存在的旧版本WsFilter类，而非lib目录下的官方实现。

按排查优先级排列的可行解决方案 #

1. 清理Web应用内部的冲突打包依赖 #

这是该问题最高发的诱因：

• 打开已部署应用的WEB-INF/lib目录，删除所有和Tomcat容器内置功能重合的jar包，重点排查三类文件：
  • 任意版本的tomcat-websocket.jar
  • 任意版本的websocket-api.jar
  • 应用打包时显式引入的javax.servlet-api依赖
• 检查项目构建配置（Maven/Gradle等），将上述由容器提供的依赖的作用域调整为provided，确保这类依赖仅参与编译过程，不会被打包进最终的部署WAR包。以Maven为例，正确的依赖配置参考：

  <dependency>
      <groupId>org.apache.tomcat</groupId>
      <artifactId>tomcat-websocket</artifactId>
      <version>9.0.43</version>
      <scope>provided</scope>
  </dependency>
  

• 确认应用代码中没有手动导入、注册旧版本的WsFilter实现，所有WebSocket相关的类引用均指向类路径下的官方Tomcat实现。

2. 排查Windows服务模式下的类加载路径冲突 #

Tomcat以Windows服务运行时，很容易出现升级完成后类加载路径仍指向旧版本目录的问题：

• 打开对应Tomcat服务的配置工具（和服务绑定的tomcat9w.exe），在Java配置页检查类路径加载项，确认所有加载的jar文件都来自当前9.0.43版本的官方安装目录，没有混入旧版本Tomcat路径下的tomcat-websocket.jar、servlet-api.jar
• 检查Tomcat自定义类加载目录（如shared/classes、common/lib），清理目录中存放的非官方class文件、被修改过的tomcat-websocket.jar，替换为9.0.43官方发行包lib目录下的同版本原始jar
• 确认Windows服务关联的CATALINA_HOME环境变量，指向的是升级后的9.0.43版本安装根目录，而非旧版本的残留路径。

3. 应急兜底处理 #

如果完成上述排查仍存在报错：

• 不要直接解包、修改tomcat-websocket.jar中的class文件再重新打包，这类自定义操作极易出现接口方法签名不匹配的问题
• 可以直接用官方9.0.43发行包lib目录下的原始tomcat-websocket.jar，替换当前Tomcat安装目录lib下的同名文件，确保jar文件和官方包完全一致
• 如果业务上需要自定义WebSocket过滤逻辑，不要修改容器自带的WsFilter，而是自行实现javax.servlet.Filter接口的自定义过滤器，通过配置类或web.xml手动注册生效。

踩坑提示：升级Tomcat时如果采用直接覆盖拷贝文件的方式，很容易残留旧版本的同名jar，导致类加载时优先加载到旧实现。这种场景下建议重新部署完整的9.0.43官方发行包，清理旧目录下的所有残留文件后再配置Windows服务。

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