在Spring中使用LOG4J为日志输出的插件已有一段日子了,但有时候发现日志文件虽然是已经在根据自己的理想存放了,但还会有些莫名其妙的项目日志文件出现tomcat内(因为项目的日志文件都以项目命名嘛,所以比较容易区分这些log)。这些令我纠结的日志文件,让我在改善一下LOG4J的配置。才发现,之前用的配置方式真是弱爆了。
1.先说自己比较理想的存放日志路径。
我比较喜欢把日志文件放在项目的WEB-INF下,然后当然有个文件夹叫logs。logs相信很多人都会存在在这样的目录下,但放在WEB-INF目录下相信还是有些人不理解。其实当然是为了资源保护了。
2.旧的方式
编写Servlet在项目部署的时候重置log4j配置文件中的日志文件存放路径。
web.xml配置如下:
- <servlet>
- <servlet-name>log4j-init</servlet-name>
- <servlet-class>com.foo.log.Log4jInit</servlet-class>
- <init-param>
- <param-name>log4j_properties_path</param-name>
- <param-value>WEB-INF/classes/log4j.properties</param-value>
- </init-param>
- <load-on-startup>1</load-on-startup>
- </servlet>
Log4Init的代码就不贴了,网上也比较多。主要作用就是修改原有的log4j.appender的File配置修改为现在项目部署的绝对路径,方法多样,功能都一样!
问题产生了:
这种方式在Spring环境中还是会生成一些多余日志文件。因为在项目部署时,spring初始化比配置的Servlet启动的还早,所以原有的默认日志存放路径就先生效了(虽然没什么内容,也不对项目有什么影响)。
3.有没有更好的配置方式呢?
使用Spring提供的日志配置方法
web.xml添加如下代码:
- <context-param>
- <param-name>webAppRootKey</param-name>
- <param-value>project</param-value>
- </context-param>
- <context-param>
- <param-name>log4jConfigLocation</param-name>
- <param-value>WEB-INF/classes/log4j.properties</param-value>
- </context-param>
- <listener>
- <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
- </listener>
webAppRootKey: 配置项目的别名,上面配置别名为project。若你部署的项目不在tomcat中的话这个可以忽略,因为tomcat没为每个应用配置不同的webappRoot属性,所以如果出现两个或以上相同的应用属性名的话就会报错了。
然后修改log4j.properties的配置,把日志文件输出的路径配置修改为:
log4j.appender.A1.File=${project}WEB-INF/logs/Project.log
A1是我的appender命名。 ${project}是使用上述web.xml中的应用别名从而获取应用的绝对路径。
注:若不需要配置应用别名的话,即没配置webAppRootKey。可以直接这么写:
log4j.appender.A1.File=${webapp.root}WEB-INF/logs/Project.log
webapp.root为默认属性。若有配置webAppRootKey的话就被覆盖。
题外:
1.还有一种方式是使用环境变量,例如${catalina.home}。不过这样同样也会产生多余的log的,道理跟用Servlet一样。
当然,如果你不像我这么纠结这些多余的log的话。活得也比较轻松。。。
2.而在不同的操作系统中的路径分割符是不同的,linux是 "/" ,而windows是 "",但目前的写法在两个环境中同样用tomcat测试是没问题的。虽然在windows的时候,初始化的日志看到的路径有点别扭。不过仿佛记得在一些应用服务器中会产生不兼容....
3.推荐默认情况下配置文件log4j.appender.A1.File=poject.log,而项目发布前,用ANT等脚本把路径修改为log4j.appender.A1.File=${project}WEB-INF/logs/Project.log 这样做的好处是,在用junit测试时,生成的日志文件就在项目的根路径中,容易处理或忽略。