WebSphere Liberty中EAR内WAR类与库无法被类加载器加载求助

针对迁移后WAR模块类/库无法加载的问题，核心是对齐WebSphere Traditional的独立WAR类加载器和PARENT_LAST委托策略，以下是Liberty专属的配置方案：

核心配置（server.xml） #

在<application>元素内为EAR全局配置PARENT_LAST，同时为每个WAR模块单独声明独立类加载器，确保WAR自身的WEB-INF/classes和WEB-INF/lib优先被加载：

<application id="your-ear-app" name="your-ear-app" location="your-app.ear" type="ear">
    <!-- EAR级类加载器：全局PARENT_LAST，允许访问第三方库 -->
    <classloader delegation="parentLast" apiTypeVisibility="+third-party"/>
    
    <!-- 第一个WAR模块：独立类加载器，继承PARENT_LAST策略 -->
    <webApplication id="webapp1" name="webapp1" location="webapp1.war">
        <classloader delegation="parentLast" apiTypeVisibility="+third-party" commonLibraryRef=""/>
    </webApplication>
    
    <!-- 第二个WAR模块：同上述配置，实现独立类加载 -->
    <webApplication id="webapp2" name="webapp2" location="webapp2.war">
        <classloader delegation="parentLast" apiTypeVisibility="+third-party" commonLibraryRef=""/>
    </webApplication>
</application>

关键配置说明 #

• commonLibraryRef=""：强制WAR使用自身独立的类加载器，不共享EAR的类加载上下文，对应Traditional中“每个WAR使用独立类加载器”的设置。
• 每个WAR单独配置<classloader>：覆盖Liberty默认的WAR类加载继承逻辑，确保WEB-INF/classes的应用类优先于EAR层级类被加载。
• apiTypeVisibility="+third-party"：解决第三方库的API可见性问题，避免类加载时无法识别非Java EE规范的第三方类。

辅助验证与排查 #

1. 检查application.xml
   确保EAR的部署描述符中没有自定义类加载配置（如<class-loader>元素），若存在需移除，避免与Liberty的server.xml配置冲突。

2. 启用类加载调试日志
   在server.xml中添加日志配置，追踪类加载路径，确认WAR的类是否被正确扫描：

   <logging traceSpecification="com.ibm.ws.classloader.*=all"/>
   

   启动服务器后查看logs/trace.log，搜索目标类名，确认加载来源是否为webapp1/WEB-INF/classes或对应WAR的WEB-INF/lib。

3. 恢复原EAR结构
   无需手动将WAR/lib复制到EAR/lib，上述配置会让WAR自身的库被优先加载，保持原部署结构与Traditional一致。

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