I'm not sure why it wouldn't be happening on initial startup, but is it possible that the webapp is finding a log4j.xml file in a parent classloader, which would be used in preference (by Log4j's auto-configuration mechanism) to log4j.properties in each webapp? If that's not the case, you aren't, by chance, running Tomcat-5.5 under JBoss or something like that, are you? Because at that point, the classloader behavior changes to not be child-first by default, which would explain the behavior you are seeing. Are you double-dog sure that log4j.jar is in *each* webapp's WEB-INF/lib?
Jake Quoting Javier Gonzalez <[EMAIL PROTECTED]>: > Hi, > > I've got a tomcat 5.5 server running a bunch of webapps, each one with > its own copy of log4j.jar and log4j.properties. Each one does terse > logs to the tomcat console and a detailed log to a separate log file > for each webapp. > > The problem is that, when I reload a context, that context's log4j > configuration seems to take over the log4j configurations of every > webapp, and all the applications start logging with that > configuration, which is no good at all, since the terse logs now all > come formatted with the reloaded context's pattern, and the verbose > logs are lost since the only verbose log file logged to is the > reloaded context's, while the other log files sit untouched, and every > additivity configuration of the other webapps is lost. > > Can anybody shed some light on this? > > Thanks in advance, > > -- > Javier Gonzalez Nicolini > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
