使用 JRuby 进行非确定性日志记录 + Tomcat6 +日志4j

发布于 2024-12-29 12:09:21 字数 193 浏览 1 评论 0原文

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

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

我可以检查哪些事情来了解为什么日志在我的环境中如此不可靠?

I'm using log4j for logging in my JRuby on Rails application. Every single time I push the application out, logs are getting appended to different end destinations. Sometimes it's catalina.out. sometimes it's localhost-date.log. sometimes it's catalina-date.log.

I'm not really sure why it's not the same every single time.

what are some things I can check as to why logs are so unreliable in my environment?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

靖瑶 2025-01-05 12:09:21

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

这只是黑暗中的短暂,但每次我遇到一些奇怪的 log4j 和/或Commons Logging我立即回想起并重新审视后者的详细记录问题(请参阅在采用 commons-logging API 之前再三考虑,或者更全面的版本分类使用 Jakarta Commons Logging 时遇到的类加载器问题),在 delfuego 对 log4j 和线程上下文类加载器

您似乎偶然发现了 log4j 的主要问题(以及
Apache Commons Logging 库),即他们有一个可笑的
很难发现正确的类加载器并与之交互
它们正在被使用。

考虑到类加载器问题的本质,我可以想象它也会解决您的问题,即根据当前最终在日志记录中连接的类加载器,它可能会使用不同的日志记录属性搜索路径和各自的默认值,请参阅为什么 log4j 在 J2EE 或 WAR 中找不到我的属性文件应用程序?

简短的回答:log4j 类和属性文件不是
在同一个类加载器的范围内。

长答案(以及如何处理):J2EE 或 Servlet 容器
利用Java 的类加载系统。 Sun改变了类加载的方式
与 Java 2 的版本配合使用。在 Java 2 中,安排了类加载器
处于等级制度的亲子关系中。当子类加载器
需要查找类或资源时,它首先将请求委托给
家长。 [...]

通过切换到 Simple Logging Facade for Java (SLF4J) 确实(顺便说一句,它恰好与 log4j 具有相同的作者,Ceki Gülcü),同样由 delfuego 建议:

[...] 最重要的信息是,主要驱动力之一
新的日志框架 SL4J 旨在消除这些问题
完全。你可能想把它换掉,看看你的生活是否已经成功
更容易。

最后,John 与 在 Tomcat jruby-rack 上为 Rails 3 应用程序使用 log4j 进行日志记录 似乎通过 SL4J 也是如此。

祝你好运!

This is pretty weird indeed - are you by chance using Apache Commons Logging as well?

It's just a short in the dark, but every time I experience something weird with log4j and/or Commons Logging I immediately recall and revisit the well documented problems with the latter specifically (see Think again before adopting the commons-logging API, or the even more comprehensive version Taxonomy of class loader problems encountered when using Jakarta Commons Logging), concisely summarized in delfuego's answer for 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.

Given the very nature of the classloader issue, I could imagine it tripping your problem as well, i.e. depending on which classloader currently ended up wiring in your logging, it might use a different logging properties search path and respective defaults as well, see 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. [...]

The mentioned problems are usually easy to remedy by switching to Simple Logging Facade for Java (SLF4J) indeed (which happens to have the same author as log4j btw., Ceki Gülcü), as likewise suggested by 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.

Finally, John's (as of today unresolved) adventure with Logging with log4j on tomcat jruby-rack for a Rails 3 application seems to hint on respective issues and a possible solution via SL4J as well.

Good luck!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文