过看日志,发现was服务器上的server上的systemout.log太大,打开后发现有关业务数据的日志也全部写在了这个里面,于是进行改进。
先是改写了工程中的log4j配置文件,如下所示
view plaincopy to clipboardprint?
01.log4j.rootLogger=ERROR,A1
02.log4j.logger.CLIENT=INFO,R
03.log4j.logger.FUNCTION=INFO,FUNC
04.
05.log4j.additivity.CLIENT=false
06.log4j.additivity.FUNCTION=false
07.
08.log4j.appender.A1=org.apache.log4j.ConsoleAppender
09.log4j.appender.A1.layout=org.apache.log4j.PatternLayout
10.log4j.appender.A1.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss:SSSS} [%p] %m%n
11.
12.#log4j.appender.R=org.apache.log4j.FileAppender
13.log4j.appender.R.Encoding=utf-8
14.log4j.appender.R=org.apache.log4j.DailyRollingFileAppender
15.log4j.appender.R.File=./logs/cussLog/dos_access.log
16.log4j.appender.R.layout=org.apache.log4j.PatternLayout
17.log4j.appender.R.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss:SSSS} [%p] %m%n
18.
19.log4j.appender.R.MaxFileSize=100MB
20.
21.
22.log4j.appender.FUNC.Encoding=utf-8
23.log4j.appender.FUNC=org.apache.log4j.DailyRollingFileAppender
24.log4j.appender.FUNC.File=./logs/cussLog/dos_txn.log
25.log4j.appender.FUNC.layout=org.apache.log4j.PatternLayout
26.log4j.appender.FUNC.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss:SSSS} [%p] %m%n
27.
28.log4j.appender.FUNC.MaxFileSize=100MB
log4j.rootLogger=ERROR,A1
log4j.logger.CLIENT=INFO,R
log4j.logger.FUNCTION=INFO,FUNC
log4j.additivity.CLIENT=false
log4j.additivity.FUNCTION=false
log4j.appender.A1=org.apache.log4j.ConsoleAppender
log4j.appender.A1.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss:SSSS} [%p] %m%n
#log4j.appender.R=org.apache.log4j.FileAppender
log4j.appender.R.Encoding=utf-8
log4j.appender.R=org.apache.log4j.DailyRollingFileAppender
log4j.appender.R.File=./logs/cussLog/dos_access.log
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss:SSSS} [%p] %m%n
log4j.appender.R.MaxFileSize=100MB
log4j.appender.FUNC.Encoding=utf-8
log4j.appender.FUNC=org.apache.log4j.DailyRollingFileAppender
log4j.appender.FUNC.File=./logs/cussLog/dos_txn.log
log4j.appender.FUNC.layout=org.apache.log4j.PatternLayout
log4j.appender.FUNC.layout.ConversionPattern=%-d{yyyy-MM-dd HH:mm:ss:SSSS} [%p] %m%n
log4j.appender.FUNC.MaxFileSize=100MB
主要是添加了additivity,使得自定义的两个logger不往父类的logger里面再写日志,这样就可以将业务日志和系统日志分离开,进行单独的配置和管理。
但是修改后在tomcat上测试成功后,转移到了was服务器上就遇到了一个这样的问题,全部日志仍然都写在了systemout里面,业务数据日志文件为空。
开始怀疑是log4j的配置问题,检查了很多遍,was服务器上使用的共享库也检查了,server也重启了,甚至node agent也重启了,还是一样的问题。
于是开始从tomcat与was的区别开始考虑。
以前代码中写业务日志文件的部分代码大概为:
view plaincopy to clipboardprint?
01.Log log = LogFactory.getLog(getClass())
Log log = LogFactory.getLog(getClass())
为了找到原因,将写日志文件的代码修改为:
view plaincopy to clipboardprint?
01.Logger log = Logger.getLogger(a.class)
Logger log = Logger.getLogger(a.class)
改成上述方式写业务数据成功,并且系统日志和业务日志也实现了分离。
Google了一下,相关问题还不少,apache甚至专门有文档来说明这个问题。
先说解决方法:
1. 用 Logger log = Logger.getLogger(BudgetQryServiceImpl.class)
直接获得 log4j 的 Logger 实例;
2. 仍用 Log log = LogFactory.getLog(getClass()) 但必须在应用目录的 META-INF/services 中加个文件 org.apache.commons.logging.LogFactory
内容为: org.apache.commons.logging.impl.LogFactoryImpl 。默认时,日志实现会被 websphere 的日志组件接管。
原因分析:
WAS也是用的commons-logging日志框架,commons-logging中LogFactory 获得实现的顺序是
1. 从应用的 META-INF/services/org.apache.commons.logging.LogFactory 中获得 LogFactory实现
2. 从系统环境中获得 org.qpache.commons.logging.LogFactory 获得 LogFactory 实现
3. 从 classpath 下的 commons-logging.properties 文件中获得 LogFactory 实现
而之所以在 tomcat 下表现良好的 log4j 日志输出放到 was 下不灵了,是因为 was 在第二步截住了,was 有一个系统环境变量 org.qpache.commons.logging.LogFactory 的值为 com.ibm.was.commons.logging.TrLogFactory,这个类在 ws-commons-logging.jar 中。
所以我们在使用 commons-logging 时,要能应用到所期望的 LogFactory 实现就要在第一步获得 LogFactory 实现,这就是前面的第二种方法。 而 Logger log = Logger.getLogger(a.class) 用直接得到 Log4j 的 Logger 也就是跳开了用 LogFactory 来获得 Logger 的尴尬。
我相信一句话,任何事情的发生都是有其原因的。小小的日志文件也是一样。
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/iv2005/archive/2010/07/26/5767381.aspx
分享到:
相关推荐
was报错日志
WAS上log4j日志不能输出(ibatis)sql语句解决办法[借鉴].pdf
1.SQL SERVER Always On收缩日志文件详细操作; 2.针对收缩日志出现“cannot be shrunk until all secondaries have moved past the point where the log was added ”问题的分析及解决方法;
针对WAS6.1,对线程数、jvm,日志以及数据库连接进行性能调优
WAS8.5.5.0图形化界面升级至8.5.5.13及配置JDK1.8手册
spring项目启动报错,@EnableAsync annotation metadata was not injected日志
产服务器宕机。从当时的日志情况来看请求操作失败,资源等待操作,,现实抛出内存溢出(OutOfMemoryException)异常
日志文件说明: (1).activity.log 打开方式:Log Analyzer in IBM Support Assistant or Log and Trace Analyzer(LTA) in Application Server Toolkit(AST) -consolidates key messages on a particular node...
分析GC日志native_stderr.log(可分析WAS6.1版本)
项目启动后访问页面,页面显示Uncaught initialization Exception created by servlet这个错误.查看日志会报找不到index()的异常。
该文档为was7.0版本详细的服务器安装配置及应用服务包部署指导以及简单的日志定位排错指导。
eclipse与Websphere 6.1进行紧密合作、并实现在eclipse中进行was的启动和日志查看、并实现类自动加载。
在安装SQL时遇到挂起问题,出现安装程序配置服务器失败参考服务器错误日志,运行相应文本就行,操作简单
(******************************************************************************) (* 模 块 名: HSLogger4D.Pas *) (* 别 名: 多任务线程安全日志接口-进程独立版 *) (* 作 者: Unsigned(僵哥) *) ...
事故背景:一大早还在路上,群里...发现磁盘io问题,继续查看sqlserver日志,发现原因: “Autogrow of file ‘xxxx_log’ in database ‘xxxx’ was cancelled by user or timed out after 3398 milliseconds. Use
TOMCAT昨天突然自己宕掉服务了,怎么重起都不行,后来查看logs中catalina.out 日志发现如下错误 INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not ...
WAS V8 安装的问题基本通过分析安装 / 卸载的 log(日志文件)进行问题诊断。 IM 的日志文件主要在 IM application data location 里面,包括如下几种文件:
was6.0部署时产生的异常
WAS允许你以不同的方式创建测试脚本:你可以通过使用浏览器走一遍站点来录制脚本,可以从服务器的日志文件导入URL,或者从一个网络内容文件夹选择一个文件。当然,你也可以手工地输入URL来创建一个新的测试脚本。
ALML/3/CPU_RESET: The CANbus node of [STRING] detects that CPU was reset, the barcode is: [STRING1]. 日志含义 CANbus节点检测到CPU被复位。 可能原因 原因1:单板复位。 原因2:底层CANbus异常复位。 处理...