2

我已经搜索了很多，但找不到答案。我刚刚升级了 STS（从 3.2 开始），所以我可以试用 Tomcat 8（从 7.0.53 开始）。我有 STS 3.6.2 和 Tomcat 8.0.15。添加 TC8 服务器并对其进行配置后，它拒绝启动，并出现以下根错误：

java.lang.ClassNotFoundException: org.apache.juli.WebappProperties

所以我读了很多，发现这个指南从通过 Juli 的硬编码公共日志切换到 Log4J 并按照它没有任何运气。相关摘录：

Apache Tomcat 的内部日志记录使用 JULI，它是 Apache Commons Logging 的打包重命名分支，默认情况下，它被硬编码为使用 java.util.logging 框架。这确保了 Tomcat 的内部日志记录和任何 Web 应用程序日志记录将保持独立，即使 Web 应用程序使用 Apache Commons Logging。

要将 Tomcat 配置为对其内部日志记录使用替代日志记录框架，必须将硬编码以使用 java.util.logging 的 JULI 实现替换为保留完整 Commons Logging 发现机制的 JULI 实现。这种实现是作为附加组件提供的。可以在下面找到有关如何配置 Tomcat 以使用 Log4j 框架进行内部日志记录的说明。

我还从这里找到了这个答案（对一个不同的问题）和这个问题，后者似乎有一个几乎相同的问题，没有任何解决方案。

我在我的 Tomcat 的 bin/lib 文件夹中搜索了所有 JAR，但没有找到这样的类（包括各种版本的tomcat-juli.jar和tomcat-juli-adapters.jar）。除了前面链接的 Tomcat 8 Logging 指南外，我在 Internet 上几乎找不到任何关于此类/接口的参考。那么，问题来了：Tomcat为什么要找这个类？

再次来自链接指南，它是这样说的：

如果使用实现 org.apache.juli.WebappProperties接口的类加载器（Tomcat 的 Web 应用程序类加载器），那么也会对 执行属性替换 ${classloader.webappName}，${classloader.hostName}并 ${classloader.serviceName}分别替换为 Web 应用程序名称、主机名和服务名称。

为什么我的 Tomcat 类加载器实际上没有实现它，或者它为什么没有找到它？

4

3 回答 3

4

我们的 Ant Tomcat 配置过程将 Tomcat 7 的 tomcat-juli.jar 复制到了 Tomcat 8，从而导致了该问题。

从 Apache 的 Tomcat Extras 部分获取正确的 Tomcat 8 的 tomcat-juli.jar 解决了这个问题。

于 2015-10-19T18:54:19.333 回答
1

该接口位于 tomcat-juli.jar 中，Tomcat 的 Web 应用程序类加载器实现了该接口。

您无需切换到基于 log4j 的日志记录即可解决此问题。

tomcat-juli.jar （应该在 bin 目录中）似乎在某处的类路径中丢失。不确定这是否是您需要调整 Eclipse 与 Apache Tomcat 的集成的配置错误。

我建议您从 ASF 安装干净的 Tomcat 8.0.15 开始，确保它可以从命令行运行，然后尝试将其与 STS/Eclipse 集成。

于 2014-11-13T21:41:23.957 回答
1

检查您正在使用的 Tomcat 上的版本。我们现在默认使用 Tomcat 8.5.4 或更高版本。如果你想使用旧版本，你需要添加 tomcat-juli，如发行说明中所述

于 2017-11-23T06:33:43.527 回答