1

我们目前正在将我们的应用程序从生产环境迁移到全新的数据中心。

  • 当前生产环境：Java 1.4、Java EE 3、WAS 5.1、JSF 2.1
  • 新数据中心环境：Java 1.5、Java EE 5、WAS 6.1、JSF 2.1
我们的应用程序基于 JSF 2.1 构建，并在其中一个 AJAX 调用中包含以下代码： 
request.getSession().getServletContext().getRequestDispatcher(
                    “/results.faces”）.include（请求，响应）；
这就是我们遇到问题的地方。

案例 1：EAR 结构符合标准规范
。EAR -> WAR -> WEB-INF -> lib -> *.jar（所有应用程序特定的 jar 都在 WEB-INF/lib 下）。这不起作用，我们继续获取类加载器未找到的类的异常。此外，上述 AJAX 调用失败（未生成输出）

案例 2：EAR 包含根目录上的所有应用程序 JAR 文件（MANIFEST.MF 具有手动指定的类路径）。
这种方法非常有效，并且所有 JAR 文件都被加载，没有任何问题。此外，AJAX 调用也很顺利。

任何想法为什么会发生这种情况。

- 阿什什

4

1 回答 1

1

是的，这是因为 Java EE 应用服务器有一个类加载器的层次结构，如下所示：首先调用引导类加载器；接下来是 EAR 级别的类加载器，然后是 WAR 级别的类加载器。更高级别的类加载器不会在下面查找他们需要的类。如果他们没有找到他们需要的东西，则会抛出 ClassNotFoundException。

所以 WEB-INF/lib 中的 JAR 对 EAR 级别的类加载器是不可见的。当您将这些 JAR 向上移动时，您就可以解决问题。它也使所有这些 JAR 对您 EAR 中的所有 WAR 可见。

您可能要检查的一件事是 web.xml 和其他文件的规范。servlet 和 JSP 规范在此过程中发生了变化，因此像 JSTL 之类的 JAR 从 1.0 版到 1.1 版。您可能需要仔细检查您的 web.xml 和所有 JAR，以确保它们与您的 Java EE 应用服务器支持的规范相匹配。

不幸的是，升级应用服务器并不像插入 EAR 或 WAR 那样简单。

于 2009-04-29T22:25:53.950 回答