LOG4J 作为单例，无论如何都要避免 web 环境中 log4j 日志记录冲突
我们有一个j2ee web环境。服务器配置为在多个 Web 应用程序之间共享会话和可能的类加载器。基本上，一个类加载器可以为多个 Web 应用程序提供服务。
这似乎会导致 log4j 出现问题。不同的 web 应用程序可能有不同的 log4j 配置，但日志记录将移动到同一文件。
在线阅读，看起来 log4j 在附加程序和其他功能方面大量使用单例。
有没有一种方法可以将一个 web 应用程序的 log4j 配置与另一个 web 应用程序完全分开。
服务器：websphere6+
Log4j：1.4.2
Java：1.5
Example log4j.properties (webapp1):
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=/usr/local/file1.log
log4j.additivity.com.app=false
Example log4j.properties (webapp2):
log4j.appender.Z=org.apache.log4j.RollingFileAppender
log4j.appender.Z.File=/usr/local/file2.log
log4j.additivity.com.app=false
现在，来自 webapp2 的日志记录可能会出现在 webapp1 日志中，反之亦然。我们不希望这样。
可能的解决方案：
是否可以添加自定义文件附加程序？这可以解决问题吗？我将向自定义附加程序添加哪些代码？
是否可以更改 log4j 初始化。例如，我可以使用一些启动 servlet 来为每个 Web 应用程序加载 logj4。
We have a j2ee web environment. The server is configured to share session and possibly classloaders across multiple webapps. Basically, one classloader could server multiple web apps.
This seems to cause issues with log4j. Different webapps could have different log4j configurations but the logging will move to the same file.
Reading online, it looks like log4j uses singletons a lot, in terms of the appenders and other functionality.
Is there a way to completely separate the log4j configurations from one webapp from the other.
Server: websphere6+
Log4j: 1.4.2
Java: 1.5
Example log4j.properties (webapp1):
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=/usr/local/file1.log
log4j.additivity.com.app=false
Example log4j.properties (webapp2):
log4j.appender.Z=org.apache.log4j.RollingFileAppender
log4j.appender.Z.File=/usr/local/file2.log
log4j.additivity.com.app=false
Right now, logging from webapp2 may appear in the webapp1 logs and vice verse. We don't want that.
Possible Solution:
It might be possible to add a custom file appender? Would that fix the issue and what code would I add to the custom appender?
Is it possible to change the log4j initialization. E.g., could I use some startup servlet to load logj4 for each webapp.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您有两种方法可以解决您的问题：
配置您的应用程序。服务器，因此它不会在多个 Web 应用程序之间共享类加载器。当它执行此操作时，由于 log4j 的性质，只会加载一个 log4j.properties 文件。
如果您离开应用程序。服务器，以便共享类加载器，然后使用一个“主”log4j.properties 文件。在其中，为每个应用程序的根定义附加程序（例如
com.mycompany.webapp1、com.mycompany.webapp2）没有完美的解决方案。特别是，如果您的 Web 应用程序共享一些使用 log4j 的类，则第二个将会出现问题。在这种情况下，两个应用程序的日志最终将保存在同一个文件中。
你的问题很常见。要了解有关此主题的更多信息，请搜索“log4j 和 j2ee”。
编辑：由于解决方案 1 和 2 不可行，您可以尝试其他方法：
每个应用程序使用 log4j.properties 文件。在其中每一个中，为其根定义一个附加程序（如解决方案 2 中所述），并将可加性设置为 false。如果它们之间存在任何类共享，这也不会是完美的。
以编程方式为每个应用程序配置 log4j。由于它们是遗留应用程序，这可能很困难。一种方法是对每个 ServletContextListener 使用 ServletContextListener应用程序并在应用程序启动时配置 log4j。我没有亲自尝试过这一点，所以我不能 100% 确定是否会因共享类加载器而发生冲突。
Log4j 不会再真正更新了。 log4j 的创建者 Ceki Gülcü 表示，他将把精力集中在 slf4j 和 logback，纠正他在log4j开发过程中犯的一些错误。
You have two ways to solve your problem:
Configure your app. server so it doesn't share classloaders across multiple webapps. When it does do that, because of log4j's nature, only one log4j.properties file will be loaded.
If you leave the app. server so it shares classloaders, then use one "master" log4j.properties file. In it, define appenders for root of every one of your applications (example
com.mycompany.webapp1,com.mycompany.webapp2)No solution is perfect. Particularly, the second one will be problematic if your web apps share some classes that use log4j. In that case, logs from both apps will end up in the same file.
Your problem is a common one. To understand more about this topic, google for "log4j and j2ee".
Edit: since solutions 1 and 2 aren't feasible, you could try something else:
Use log4j.properties file per application. In every one of them, define an appender for their root (as explained in solution 2), and set additivity to false. This also won't be perfect if there is any class sharing between them.
Configure log4j programatically for every application. Since they're legacy applications, this could be tough. One way to do it is to use ServletContextListener for every application and configure log4j on application startup. I haven't personally tried this, so I'm not 100% sure if there will be clashes due to shared classloaders.
Log4j won't be really updated anymore. Ceki Gülcü, who created log4j, stated that he will focus his efforts on slf4j and logback, to correct some mistakes he did during development of log4j.