Tomcat/lib部署MY-PLUGIN后无法将实例强转为IPlugin接口的问题咨询

问题本质 #

这是Java类加载机制导致的典型问题：同一个全限定名的Java类，若由不同的类加载器加载，会被JVM视为完全不同的类型。

具体到你的场景：

• 部署在Tomcat webapps下的Web应用，其依赖的IPlugin接口由Web应用专属的WebAppClassLoader加载（该类加载器负责加载WEB-INF/classes和WEB-INF/lib下的类）。
• 放入Tomcat/lib的MY-PLUGIN.jar中的MyPlugin类，由Tomcat的CommonClassLoader加载，它依赖的IPlugin接口同样由CommonClassLoader加载。

JVM判断两个类是否为同一类型，不仅看全限定类名，还要校验加载它们的类加载器。所以这两个IPlugin的Class对象是完全独立的实例，自然equals判断返回false，强制类型转换时会抛出ClassCastException。

解决办法 #

1. 统一接口的加载来源 #

将MY-API的jar包也放到Tomcat/lib目录下。这样无论是Web应用还是MY-PLUGIN，它们的IPlugin接口都会由CommonClassLoader加载，类标识完全一致，类型转换和equals判断都会正常工作。

适用场景：多个Web应用需要共享这个插件接口的场景。

2. 调整插件jar的存放位置 #

把MY-PLUGIN.jar从Tomcat/lib移到你的Web应用的WEB-INF/lib目录下。此时MyPlugin类会由WebAppClassLoader加载，它依赖的IPlugin接口和Web应用自身的IPlugin是同一个类加载器加载的，类型匹配问题自然解决。

适用场景：该插件仅为当前Web应用服务的场景。

3. 修改Tomcat类加载委托顺序（谨慎使用） #

在Web应用的META-INF/context.xml中添加如下配置：

<Context>
  <Loader delegate="true"/>
</Context>

delegate="true"会让WebAppClassLoader先委托父类加载器（即CommonClassLoader）加载类，这样Web应用中的IPlugin会优先从Tomcat/lib加载，和MY-PLUGIN中的IPlugin保持一致。

注意：这种方式可能引发类版本冲突，比如Web应用依赖的其他类在Tomcat/lib和WEB-INF/lib存在不同版本时，会优先加载Tomcat/lib的版本，可能导致预期外的问题，非必要不推荐使用。

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