Sorry for the delay, had a few vacation days.
I ran some tests to verify Log4J config at webapp vs server level and had these additional observations: The log4j.properties file in CATALINA_HOME/lib is still used for initialization unless overridden in the default locations (log4j.properties or log4j.xml) by the webapp; using an alternate location via e.g. Spring Log4jContextListener will result in two LogManagers configured against the same files. JDK logging is still initialized by Tomcat's default logging.properties, resulting in several zero-length files in CATALINA_BASE/logs. So overall that's three changes to the Tomcat documentation for Log4J: Use tomcat-juli.jar and tomcat-juli-adapters.jar from the archives; don't build them yourself (until the build script is fixed) Webapp must configure Log4j from the default locations (log4j.xml or log4j.properties at top-level in the classpath) or else supply an empty file at one of these locations to suppress the one on the server classpath CATALINA_BASE/conf/logging.properties should be deleted or renamed. Jonathan Ross wrote: > > Thanks, this worked. I downloaded tomcat-juli.jar from > http://archive.apache.org/dist/tomcat/tomcat-6/v6.0.18/bin/extras/, > replaced my build with it, and now have log4j at the server level. (I > still need to very the classloader order prefers log4j.jar in a webapp.) > > > Mark Thomas-18 wrote: >> >> Mark Thomas wrote: >>> I have checked recently (with 6.0.18) and it worked as expected and >>> documented. >>> I'll check 6.0.20 and post the results. >> >> 6.0.20 works for me as well. It looks very much like your build >> environment is >> broken. Rather than building the extras package yourself, just download >> it. This >> works for me with 6.0.18 and 6.0.20 as documented. >> >> Mark >> > > -- View this message in context: http://www.nabble.com/Seeking-authoritative-answer-re-using-Log4J-with-v6-tp24225048p24375677.html Sent from the Tomcat - User mailing list archive at Nabble.com.
