Tomcat部署WAR与Liferay定位解析

本文深入解析了在 Liferay 7.x 与 Tomcat 集成环境下传统 WAR 文件“消失”的根本原因——Liferay 已摒弃标准 Servlet 部署模型，转而采用基于 OSGi 的模块化 Bundle（.jar）部署机制，所有插件均通过 deploy/ 目录热加载、由 OSGi 运行时统一管理生命周期；文章不仅手把手指导开发者通过检查 deploy/、osgi/modules/ 目录及 Gogo Shell 命令快速确认部署状态，更强调必须摒弃手动修改 webapps/ 下文件的旧习惯，转而在源码层通过 Gradle/Maven 精准更新 SDK 依赖、重建 Bundle 并规范清理缓存，同时借助 lb、stop、uninstall、diag 等 Shell 命令诊断和解决多版本共存引发的类加载冲突，真正帮开发者跳出路径迷思，建立以 OSGi 模块为核心的现代 Liferay 开发认知与实践范式。

本文详解在 Liferay 7.x + Tomcat 环境下，为何无法找到传统 WAR 文件，并阐明其基于 OSGi 的新型部署机制，指导开发者正确更新 SDK 依赖。

本文详解在 Liferay 7.x + Tomcat 环境下，为何无法找到传统 WAR 文件，并阐明其基于 OSGi 的新型部署机制，指导开发者正确更新 SDK 依赖。

在典型的 Tomcat 独立部署中，应用通常以 *.war 文件形式放置于 webapps/ 目录下，启动时自动解压至同名文件夹（如 myapp.war → myapp/）。但当 Tomcat 作为 Liferay 7.x 的嵌入式容器运行时，这一机制已彻底改变：Liferay 不再将插件（Portlet、Service Bundle 等）以标准 WAR 形式部署到 Tomcat 的 webapps/ 目录，而是通过其 OSGi 运行时（Felix 或 Equinox）直接加载模块化 Bundle。这意味着你反复搜索的 .war 文件根本不存在——它已被构建为 *.jar 格式的 OSGi Bundle（如 my-portlet.jar），并由 Liferay 自主管理生命周期。

? 如何确认当前部署模式？

执行以下任一操作即可验证：

• 检查 deploy/ 目录（Liferay 根目录下）：此处是热部署入口，放入 *.jar（非 .war）即触发 OSGi 安装；
• 查看 osgi/modules/ 目录：所有已部署 Bundle 均存放于此（含自动解压的 META-INF/MANIFEST.MF 及 WEB-INF/ 结构）；
• 访问 Liferay 控制台 → Gogo Shell（http://localhost:8080/c/portal/shell）并执行：

  lb | grep -i "myportlet"
  # 输出示例：123 ACTIVE    my-portlet_1.0.0 [my.portlet]

✅ 正确更新 SDK 依赖的流程

由于依赖被封装在 Bundle 的 WEB-INF/lib/（实际位于 JAR 内部），直接修改 tomcat/webapps/.../WEB-INF/lib/ 是无效且危险的——该目录由 OSGi 运行时动态生成，重启或热重载会覆盖你的手动更改。

✅ 推荐做法（面向开发与运维）：

1. 源码层更新：在模块项目（Gradle/Maven）的 build.gradle 中升级 SDK 依赖版本，重新构建：

   dependencies {
       compileOnly group: "com.example", name: "sdk-core", version: "2.5.0"
       // 注意：Liferay 7+ 推荐使用 compileOnly + providedRuntime 而非 runtime
   }

2. 重建并部署：

   ./gradlew clean build
   cp build/libs/my-portlet-1.0.0.jar $LIFERAY_HOME/deploy/

3. 清理缓存（必要时）：

   rm -rf $LIFERAY_HOME/osgi/state/ $LIFERAY_HOME/osgi/wiring/
   # ⚠️ 切勿删除 tomcat/work 或 tomcat/temp —— OSGi 不依赖它们

⚠️ 关键注意事项

• 不要手动修改 tomcat/webapps/ 下任何内容：Liferay 7.x 默认禁用 Tomcat 的自动部署（autoDeploy=false），该目录仅用于 Liferay 自身的 ROOT.war 和极少数兼容性组件；
• WEB-INF/lib 的“双版本”现象：你观察到新旧 SDK 共存，是因为 OSGi 支持多版本 Bundle 并存，而类加载器可能同时解析了旧 Bundle 的导出包与新 Bundle 的导入包——这往往引发 ClassCastException 或 NoSuchMethodError，必须通过 Gogo Shell 卸载旧版：

  stop 123    # 停止旧 Bundle（ID 来自 lb 命令）
  uninstall 123

• 验证依赖树：使用 diag 123（Bundle ID）检查未满足的约束，确保新 SDK 的 Export-Package 与消费者 Bundle 的 Import-Package 版本匹配。

掌握 Liferay 7.x 的 OSGi 部署本质，是解决“WAR 文件失踪”困惑的根本。与其在 Tomcat 目录中徒劳搜索，不如拥抱模块化思维：以 Bundle 为单元构建、部署、诊断——这才是现代 Liferay 开发的正确范式。

终于介绍完啦！小伙伴们，这篇关于《Tomcat部署WAR与Liferay定位解析》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！