log4j 在 WebSphere 中不工作
我有一个奇怪的问题，我的 log4j 日志记录在部署在 tcServer 上时可以工作，但在 WebSphere 6.1 上却不行。 我在 log4j 中指定的文件名已创建。但是，即使其他 Websphere 日志（SystemOut.log 等）已填充，它也不会填充。 我检查了 WebSphere 主目录的属性目录，那里没有冲突的 log4j 文件。
最奇怪的是它在 tcServer 上运行良好，所以它不可能是 log4j 文件本身的问题。这似乎是一些环境问题。 有人对如何解决这个问题有任何想法吗？
谢谢
I have a strange problem whereby my log4j logging works when deployed on tcServer but not on WebSphere 6.1.
The file name that I've specified in the log4j is created. However, it is not populated even though the other Websphere logs (SystemOut.log etc) are.
I've checked my WebSphere's home directory's properties directory, and there are no conflicting log4j files located there.
The strangest thing is that it works fine on tcServer so it can't be a problem with the log4j file itself. It seems like some environmental issue.
Has anyone any ideas on how to resolve this?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Log4j 和 WAS 已经在很多应用程序中发挥了很好的作用。所以这种组合无论如何都不是什么新鲜事。您是否使用 log4j 的任何包装器（例如 Commons Logging）？
打开 log4j 的调试。
-Dlog4j.debug=true 为 WAS JVM 参数。
这将提供有关 log4j 正在尝试执行的操作的信息。
这应该为 WAS 环境中发生的情况提供一些线索。
HTH
曼格鲁
Log4j and WAS have worked for good way too many applications. So this combination is not new by any means. Do you use any wrapper for log4j (e.g Commons Logging)?
Turn on debugging for log4j.
-Dlog4j.debug=true to the WAS JVM Arguments.
This will provide information about what log4j is trying to do.
This should provide some clues to what is happening in the WAS environment.
HTH
Manglu
不久前，当我们在 WebSphere 中安装 JCA 连接器时遇到了一个问题，该连接器与它自己的 log4j 库一起打包。由于连接器被加载到容器类加载器层次结构中，因此连接器中的 log4j 库有效地覆盖了我们应用程序中的 log4j。它还阻止加载我们自己的 log4j 属性，因为 log4j 已经被引导。
您还可以在 log4j 附带的 WAS 堆栈中加载一些其他库或资源。我们解决这个问题的方法是在我们的应用程序中以编程方式进行显式 log4j 初始化（读取 log4j 属性）。
We had an issue a while back when we installed a JCA connector in WebSphere that came packaged with it's own log4j lib. Since connectors gets loaded into the container classloader hierarchy, the log4j lib in the connector effectively overrode the log4j in our application. It also prevented our own log4j properties from being loaded, since log4j was already bootstrapped.
It would be that you, also, have some other library or resource loaded in your WAS stack that comes with log4j. The way we got around it was doing explicit log4j initialization (reading the log4j properties) programatically in our application.