tomcat - 使用 JRuby + Tomcat6 + log4j 的非确定性日志记录

Question

我正在使用 log4j 登录我的 JRuby on Rails 应用程序。每次我推出应用程序时，日志都会附加到不同的最终目的地。有时是 catalina.out。有时它是 localhost-date.log。有时是 catalina-date.log。

我不太确定为什么每次都不一样。

关于为什么日志在我的环境中如此不可靠，我可以检查哪些内容？

Answer 1

这确实很奇怪 - 你是否也偶然使用了 Apache Commons Logging？

这只是一头雾水，但每次我在 log4j 和/或 Commons Logging 遇到奇怪的事情时，我都会立即记忆起并重新审视后者的有据可查的问题(请参阅 Think again before adopting the commons-logging API ，或更全面的版本 Taxonomy of class loader problems encountered when using Jakarta Commons Logging )，在 delfuego 对 log4j and the thread context classloader 的回答中进行了简要总结:

You appear to have stumbled upon the major problem with log4j (and the Apache Commons Logging library), namely that they have a ridiculously hard time discovering and interacting with the right classloaders as they're being used.

鉴于类加载器问题的本质，我可以想象它也会触发您的问题，即根据当前在您的日志记录中连接的类加载器，它可能会使用不同的日志记录属性搜索路径和相应的默认值，见 Why can't log4j find my properties file in a J2EE or WAR application? :

The short answer: the log4j classes and the properties file are not within the scope of the same classloader.

The long answer (and what to do about it): J2EE or Servlet containers utilize Java's class loading system. Sun changed the way classloading works with the release of Java 2. In Java 2, classloaders are arranged in a hierarchial parent-child relationship. When a child classloader needs to find a class or a resource, it first delegates the request to the parent. [...]

提到的问题通常很容易通过切换到 Simple Logging Facade for Java (SLF4J) 来解决(顺便说一下，它恰好与 log4j 的作者相同，Ceki Gülcü)，同样由 delfuego 建议:

[...] the take-home message is that one of the primary driving forces for the new logging framework SL4J was to eliminate these issues entirely. You might want to swap it in and see if your life is made any easier.

最后，约翰(截至今天未解决)与 Logging with log4j on tomcat jruby-rack for a Rails 3 application 的冒险似乎暗示了各自的问题以及通过 SL4J 的可能解决方案。

祝你好运!