WebSphere Application Server（WAS）8.5.5教程第五讲

续前篇！

一、Web 应用部署与类加载策略

Web 应用部署与类加载策略是 WebSphere Application Server（WAS）日常管理的核心部分，尤其对运行大型企业级 Java 应用（如 BAW）非常关键。本讲将分两部分讲解：

1、目标

1. Web 应用部署：如何安装、更新、卸载 WAR/EAR 包

2. 类加载策略：如何解决类冲突、提升加载效率

2、Web 应用部署（WAR / EAR 包）

部署入口

路径如下：
应用程序 ➝ WebSphere企业应用程序

 

1. 安装新应用

步骤：

1. 点击【安装】

2. 选择上传方式：

   • 从本地上传 .war / .ear 文件

   • 或者从服务器路径安装（/opt/IBM/xyz.ear）

3. 点击【下一步】，按提示填写信息

   • 应用名称（可以修改）

   • 目标服务器（选定一个 WebSphere 实例）

   • 安装目录设置（一般保持默认）

4. 重要步骤：配置 上下文根（Context Root）

   • 例如：/bawportal，则访问地址为 http://host:port/bawportal

5. 点击【完成】，然后【保存主配置】

6. 启动应用程序（在“企业应用程序”列表中选中 ➝ 启动）

2. 更新已有应用

路径：
WebSphere企业应用程序 ➝ 点击应用名 ➝ 点击“更新”

选项：

• 更新整个 EAR 包（替换旧包）

• 更新单个模块（如只替换 *.war）

• 更新类、资源文件等（增量更新）

3. 卸载应用

路径：
WebSphere企业应用程序 ➝ 勾选目标 ➝ 点击【卸载】

注意事项：

• 安装后不要忘记点击右上角的【保存到主配置】

• 每次安装/更新后建议重启对应服务器，清理缓存

• 部署 BAW 类 Portal 或 Process App 时，路径/依赖较多，注意 WAR 中 web.xml 和 ClassPath 定义

3、类加载策略

在 WebSphere 中，不同组件之间共享类路径，有时会导致类冲突（比如 Jackson、Log4j 不同版本），所以类加载策略管理非常重要。

类加载相关配置位置：

1. 服务器级别设置：
   服务器 ➝ 点击目标服务器 ➝ 应用程序设置 ➝ 类装入器策略

2. 应用程序级别设置：
   企业应用程序 ➝ 点击应用名称 ➝ 类装入器
   或
   ➝ 模块级别设置（Web 模块 / EJB 模块）

 

两种主要策略：

策略名称 含义 推荐情况 父类优先（Parent First） 默认方式，优先加载 WAS 共享类 稳定、安全，适合大部分业务应用 父类最后（Parent Last） 优先加载应用自己提供的类（打包在 WAR/EAR 中） 防止冲突，适合使用特殊第三方包的情况

设置位置：

• 下拉选择：类装入方式（Class loader mode）
  ➤ 选择 Parent last 可优先加载应用自己的类

 

使用场景举例：

情况 建议策略 使用 Spring Boot 打包的 WAR Parent last，防止依赖冲突 部署 IBM 官方应用 Parent first（默认即可） 出现 ClassNotFoundException / NoSuchMethodError 尝试切换策略排查 多个 WAR 共用 jar 包时 建议使用 Shared Library（共享类库机制）

4、补充：共享库（Shared Libraries）

如果多个应用使用相同的 jar 包（如 log4j.jar、common-utils.jar），建议配置为共享库，避免冗余加载。

创建方式：

1. 环境 ➝ 共享库

2. 新建共享库 ➝ 指定 jar 包目录

3. 在应用级别（企业应用程序 ➝ 应用 ➝ 共享库映射）挂载该库

 

5、实战调优建议

问题 原因 应对措施 应用启动慢 类太多或依赖冲突 开启类加载跟踪、检查依赖树 类冲突报错 同类名不同版本 设置 Parent last、使用 Shared Library ClassNotFound 异常 类路径未配置 检查 WAR/EAR 中 META-INF 及 lib 应用隔离需求 多版本 jar 并存 各应用用独立类加载器或 Docker

6、总结

重点点位 说明 安装、更新、卸载入口 WebSphere企业应用程序 上下文根配置 决定 URL 访问路径 类装入策略位置 服务器级 or 应用级均可设置 推荐默认策略 Parent first（安全），遇冲突时用 Parent last

二、案例： BAW在WAS中的类加载策略与依赖管理机制

 下面来深入梳理 IBM Business Automation Workflow（BAW） 在 WebSphere Application Server (WAS) 中的 类加载策略与依赖管理机制，这有助于你深入理解 BAW 各组件运行背后的逻辑，进而定位问题、调优或安全管控。

1、BAW 在 WAS 中的部署结构概览

BAW 其实是由多个模块打包成一个或多个 企业应用（EAR） 部署到 WAS 中的，核心包括：

模块 描述 类加载来源 BAW Process Server EAR 流程执行引擎 EAR ➝ BAW Runtime jar BAW Process Portal WAR 用户门户界面 WAR ➝ Portal UI 组件 BAW Process Designer 浏览器建模工具 部署为 Web 应用或远程组件 BAW Business Rules 决策/规则服务 WAR ➝ ODM 核心库 Common Services 如 UCA、事件监听等 Shared Libraries ➝ com.lombardi., ibm.bpm.

2、类加载策略在 BAW 中的实际应用

IBM 官方默认使用策略：

应用层级 默认策略 说明 BAW EAR 主应用 Parent First 优先加载 WAS 提供的 BPM 内核类 BAW WAR 模块（如 Portal） Parent Last 避免 UI 层与 WAS 内部类冲突 扩展/定制应用 推荐 Parent Last 避免与 BAW runtime jar 冲突

可在 WAS 控制台：

• 应用程序 ➝ 企业应用程序 ➝ 点击模块 ➝ 类装入器 ➝ 设置类加载方式

示例：防止 Jackson 冲突

BAW 内置 Jackson（如 com.fasterxml.jackson.core），但你部署的自定义服务也用了别的版本？
解决方案：

• 你的自定义模块设置为 Parent Last

• 或用 Shared Library 管理 Jackson，并为各应用指定绑定版本

3、依赖管理方式

1. 内部依赖（BAW Runtime 组件）

常见 JAR 包（这些位于安装目录，例如 /opt/IBM/Workflow/lib）：

文件名 功能 bpmserver.jar BAW 流程引擎核心 teamworks.jar 老版 BPM 核心 businessrules.jar ODM 引擎 restconnector.jar REST 连接器 ucaservice.jar 调度与消息服务

这些 jar 不可擅自替换，否则会导致版本冲突或运行异常。

2. 外部依赖（自定义服务所用）

如：

• spring-core.jar

• mybatis.jar

• jackson-databind.jar

通常放置在：

• WAR 模块中的 /WEB-INF/lib

• EAR 的 lib 或 APP-INF/lib

• Shared Library 中统一管理

4、类加载调试技巧

开启类加载跟踪日志：

在 JVM 参数中添加：

-Dibm.cl.verbose=true

 可以在 WAS SystemOut.log 中看到加载类的来源，例如：

[2/20/25 13:22:11:123 CST] 00000001 SystemOut O CL Verbose: Loaded class [com.fasterxml.jackson.databind.ObjectMapper] from [file:/opt/IBM/Workflow/lib/jackson-databind.jar]

常见冲突问题排查

现象 原因 应对方式 ClassCastException 同一类被不同类加载器加载 设置 Parent Last，或统一使用 Shared Library ClassNotFoundException 类在 WAR 内未打包 检查 lib 路径，或导入共享库 Portal 页面空白 JS 库冲突或 Portal 模块类问题 检查 WAR 配置和类加载策略 自定义服务调用失败 缺 jar 或版本冲突 检查 EAR 打包结构、依赖版本匹配性

最佳实践总结

操作场景 建议 部署标准 BAW 应用 保持 IBM 默认类加载设置 部署自定义扩展 设置模块类加载为 Parent Last，放置独立 jar 多模块共享 jar 配置 Shared Library，避免重复打包 出现冲突或异常 开启类加载跟踪日志，查清加载路径 依赖管理 使用 Maven 构建打包，控制版本准确性

 未完，待续！