问题描述
我刚刚在工作中拾取了现有的Web应用程序,该应用程序应该使用Log4j记录其活动.我已经按照我的告知,完全配置了我的工作空间,以及其他所有内容(DB连接,身份验证等)都可以正常工作,除了将Nothing写入日志文件外.其他类似的应用程序没有问题记录.
当应用程序启动时,我已经查看了WebSphere控制台,那里没有错误,可能表明为什么Log4J不记录.
我向另一个开发人员提到了这一点(他曾经从事此应用程序,但没有一段时间,但比我的日期更过时了),他说这是非常奇怪的行为,但不知道为什么会这样无法登录,也没有报告任何错误.
我已经浏览了config文件和属性文件以及所有内容 ok.我怀疑log4j甚至从未读过log4j.xml,但我不确定.自从我与Log4J合作以来已经有一段时间了 - 有人在解决此类问题方面有一些好的技巧吗?
ps:此应用程序的实例已部署到各种测试/QA/PORS服务器,并且这些实例都可以登录正常.在本地工作站上,登录似乎默默失败了.
更新:因此,该应用程序的部署方式似乎确实是一个问题. 我将classloader模式更改为" parent last",并且可以看到log4j文件至少正在读取.我尝试的第一个动作触发ClassNotFoundException说找不到org.apache.commons.logging.impl.Log4jFactory.
第二更新: 我注意到了一些陌生人...该应用程序有两个战争项目 - 其中一个是针对UI的,另一个是用于某些Web服务.用于UI 的项目是成功地将其操作记录到日志文件. Web服务项目是ClassNotFoundException失败的项目.他们俩都有commons-logging.jar列为Javaee模块依赖关系,并且俩都没有特定于项目的记录配置(所有配置文件都在资源项目中).
一个主要区别在于,UI项目包含其他一些内部框架(预先编译为JARS),可能已经包含了必要的日志记录配置,也许这就是区别.
我还尝试使用答案(一个名为org.apache.commons.logging.logfactory的文件中的元I-Inf/services中的文件,其中包含一个行:" org.apache.commons.logging.impl.log4jfactory")这个问题: web ,但似乎没有帮助.
推荐答案
我更改了最终登录工作正常工作的最新一件事是将ClassLoader模式更改为" Parent_first",而War Class Loader策略则将其更改为"应用程序".初始默认配置为" parent_first"/"模块".我根据同事的建议将其更改为" parent_last"/" application",后者说记录对他们来说正常工作,这是他们为此应用程序创建新的沙箱时必须做出的唯一更改.我不确定为什么我必须使用" parent_first"/" application",但至少现在可以使用.
更新:
我尝试设置一个新的工作区,并且遇到了同样的问题.事实证明,您需要" parent_first"/" application"和一个名为org.apache.commons.logging.logging.logfactory在meta-inf/services中的文件,其中包含一行:" org.apache.commons.logging.impl.impl.log4jfactory" .没有文件会导致记录失败(通常带有一条消息,说找不到log4j).
其他推荐答案
请参阅此答案: 如何正确初始化log4j?
-dlog4j.debug对于此类问题非常有用
其他推荐答案
我只有两分钱 - 我发生了类似的事情 - 但是就我而言,我可以看到记录呼叫的一些输出.很明显,配置是从其他地方捡起的,而我正在更改的配置也没有任何影响.
在此处建议的是打开-dlog4j.debug = true之后,很明显,log4j正在拾取位于我的tomcat工作目录中的名为log4j.xml的文件.要么是我正在做的其他事情的剩菜,要么是在我错误配置的库中的某些log4j配置中以某种方式生成的.
我没有想到删除工作目录的内容(可能已经尝试过.通过-dlog4j.configuration = log4j.properties(不想使用绝对路径)(碰巧我正在使用属性文件而不是XML) - 它起作用了.
[编辑:嗯,它不适用于服务器配置.我终于找到了错误的地方 - 一些我在项目中的罐子里有一些家庭煮熟的库,有自己的log4j.xml和log4j.properties文件,显然比我自己的属性文件更早地读取/找到/找到了这些文件是从jars删除这些冗余属性文件]
问题描述
I just picked up an existing web application at work that is supposed to log its activity using Log4J. I've configured my workspace exactly as I was told to and everything else (db connection, authentication, etc...) works fine except that the nothing is being written to the log file. Other similar applications have no problem logging.
I've looked at the WebSphere console when the application starts up and there are no errors there that might indicate why Log4J isn't logging.
I mentioned this to another dev (who once worked on this application, but not for a while and is more out of date than I am on it) who remarked that it was very strange behaviour, but had no idea why it might fail to log and not report any errors.
I've gone over the config file and properties file and everything looks OK. I suspect that Log4J is never even reading the log4j.xml but I'm not certain of that. It's been a while since I've worked with Log4J - does anyone have some good tips on trouble-shooting this type of problem?
PS: There are instances of this application that are deployed to various test/QA/prod servers and these instances all log fine. It's only on local workstations that logging seems to silently fail.
Update: So it does seem to be a problem with the way the application is being deployed. I changed the classloader mode to "Parent Last" and I can see that the Log4J file is at least being read now. And the first action I attempt triggers a ClassNotFoundException saying that org.apache.commons.logging.impl.Log4jFactory cannot be found.
2nd Update: I've noticed something stranger... The application has two WAR projects - one of them is for the UI and the other is for some web services. The project that is for the UI is successfully logging its operations to the log file. The web service project is the one that fails with the ClassNotFoundException. Both of them have commons-logging.jar listed as a JavaEE module dependency, and neither of them have a project-specific logging configuration (all config files are in a Resources project).
A major difference is that that UI project includes some other in-house frameworks (pre-compiled as JARs) that might already include necessary logging configurations and maybe that's where the difference is.
I also tried to use the answer (a file named org.apache.commons.logging.LogFactory in the META-INF/services with one line containing: "org.apache.commons.logging.impl.Log4jFactory") from this question: Websphere all logs are going to SystemOut.log but it did not seem to help.
推荐答案
The most recent thing I changed that finally got logging working properly was changing the classloader mode to "PARENT_FIRST" and WAR classloader policy to "Application". The initial default configuration was "PARENT_FIRST"/"Module". I changed it to "PARENT_LAST"/"Application" on the advice of a co-worker who says logging works fine for them and this is the only change they have to make when they create a new sandbox for this application. I'm not sure why I had to go with "PARENT_FIRST"/"Application", but at least it works now.
UPDATE:
I tried setting up a new workspace and I had the same problem. It turns out you need "PARENT_FIRST"/"Application" AND a file named org.apache.commons.logging.LogFactory in the META-INF/services with one line containing: "org.apache.commons.logging.impl.Log4jFactory". Not having the file causes logging to fail (typically with a message saying that a Log4J cannot be found).
其他推荐答案
See this answer: How to initialize log4j properly?
-Dlog4j.debug is very useful for problems like this
其他推荐答案
just my two cents - i had something like this happening - but in my case i could see some output from my logging calls. it was just apparent that the configuration was picked up from somewhere else, and the one i was changing didn't have any impact.
after turning on -Dlog4j.debug=true as suggested here, it was evident that log4j was picking up a file named log4j.xml situated inside my tomcat's work directory. either it was a leftover from other stuff i was doing, or it was generated somehow from some log4j configuration in one of my misconfigured libraries.
i haven't thought of erasing the contents of work directory (could have tried.. [edit: i tried and it didn't work]) - the only thing i though of was to pass hardcoded reference to my properties file through -Dlog4j.configuration=log4j.properties (didn't want to use absolute path) (it happened that i was using a properties file and not an xml) - and it worked.
[edit: well, it didn't work for the server configuration. I finally found what was wrong - some home-cooked libraries that I was including as JARs into my project, had their own log4j.xml and log4j.properties files, which were apparently read/found earlier than my own properties file - the rightest thing was to delete these redundant property files from JARs]