SOFAArk 静态合并部署中 JSP 资源加载问题解析

问题背景

在 SOFAArk 框架下进行静态合并部署时，开发者可能会遇到模块 JSP 文件未被正确加载的问题。具体表现为模块启动时加载的资源目录指向基座工程而非模块自身，导致模块的 JSP 资源无法被访问。

问题分析

通过对 Spring Boot 和 SOFAArk 的调试分析，发现问题的根源在于资源加载机制：

1. 资源目录定位问题：ArkTomcatServletWebServerFactory 在 prepareContext 方法中调用 getValidDocumentRoot() 时，默认获取的是基座工程的 src/main/webapp 目录资源文件，而非模块自身的资源目录。

2. 类加载机制差异：在独立启动时，Spring Boot 能正确加载模块的 resources 目录；但在合并部署后，资源加载路径出现了偏差。

技术原理

SOFAArk 的静态合并部署模式下，模块和基座共享同一个 Tomcat 实例。这种架构带来了以下特性：

1. 类加载隔离：SOFAArk 通过特殊的类加载器（ArkTomcatEmbeddedWebappClassLoader）实现模块隔离。

2. 资源加载机制：Spring Boot 默认的资源加载机制未完全适配 SOFAArk 的类加载体系，导致模块资源无法被正确识别。

解决方案

基础解决方案

修改 StaticResourceJars 类的 getUrls() 方法，使其兼容 SOFAArk 的类加载体系：

class StaticResourceJars {
    List<URL> getUrls() {
        // 改造原Spring Boot，兼容SOFAArk部署无法加载到模块的目录问题
        ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
        if (classLoader instanceof ArkTomcatEmbeddedWebappClassLoader) {
            classLoader = classLoader.getParent();
        }
        if (classLoader instanceof URLClassLoader) {
            return getUrlsFrom(((URLClassLoader) classLoader).getURLs());
        }
        else {
            return getUrlsFrom(Stream.of(ManagementFactory.getRuntimeMXBean()
                .getClassPath().split(File.pathSeparator))
                .map(this::toUrl).toArray(URL[]::new));
        }
    }
}

进阶解决方案

对于模块 JSP 依赖其他 JAR 包中资源的情况，还需要修改以下 Tomcat 相关类：

1. JarFileUrlNestedJar：调整 JAR 文件资源加载逻辑
2. JarWarResource：优化 WAR 包内资源处理
3. JarWarResourceSet：完善资源集合管理

这些修改确保了模块不仅能够加载自身的 JSP 资源，还能访问依赖 JAR 包中的相关资源。

实现建议

1. 定制化 Spring Boot Starter：建议将这些修改封装成定制的 Spring Boot Starter，便于在项目中统一管理。

2. 版本兼容性：注意 Spring Boot 2.5.14 与 JDK 17 的兼容性问题，确保所有修改在不同环境下都能正常工作。

3. 资源隔离策略：在 SOFAArk 环境下，明确基座与模块的资源加载优先级和隔离策略。

总结

SOFAArk 的静态合并部署为应用带来了诸多优势，但也带来了资源加载方面的新挑战。通过深入理解 SOFAArk 的类加载机制和 Spring Boot 的资源加载原理，开发者可以针对性地解决 JSP 资源加载问题。本文提供的解决方案不仅适用于当前问题，其思路也可应用于其他类似的资源加载场景。