本文详解在 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 运行时动态生成，重启或热重载会覆盖你的手动更改。
✅ 推荐做法（面向开发与运维）：
-
源码层更新：在模块项目（Gradle/Maven）的 build.gradle 中升级 SDK 依赖版本，重新构建：
dependencies { compileOnly group: "com.example", name: "sdk-core", version: "2.5.0" // 注意：Liferay 7+ 推荐使用 compileOnly + providedRuntime 而非 runtime } -
重建并部署：
./gradlew clean build cp build/libs/my-portlet-1.0.0.jar $LIFERAY_HOME/deploy/
-
清理缓存（必要时）：
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 开发的正确范式。
