Konstantin, Thanks for sharing your experience. It was helpful.
I still have swallowOutput enabled but, with help from folks on this list, I kind of came to the same conclusion as you. I also realized that I was making a mistake by trying to have my webapp use the shared copy of log4j rather than just including its own log4j in the .war. The reason had to do with the classloader, and which log4j.properties gets loaded for my webapp versus for catalina itself. By sending another log4j with the webapp and following advice to go back to RollingFileAppender, I now have things working pretty sensibly. About the only real challenge now is dealing with things not yet smart enough to use log4j. One of those things is jamod (a Modbus protocol implementation in Java) -- and it's enough of a problem that I'm rewriting its logging :) --Chris On Fri, Jun 12, 2009 at 1:54 PM, Konstantin Kolinko<knst.koli...@gmail.com> wrote: > 2009/6/9 Christopher Piggott <cpigg...@gmail.com>: >> (...) >> This was not working, so I searched documentation and learned about: >> >> <Context swallowOutput="true"> ... </Context> >> >> However, this swallowOutput doesn't seem to work. I tried putting >> this in several places: >> (...) >> > > If you are still puzzled with swallowOutput mistery, here is my experience. > > I tried a similar thing once, not with log4j, but with JULI in TC 5.5, > and also found > that swallowOutput does not work with logging frameworks. > > The reason, as I see it, is the following: > 1. to implement this functionality, Tomcat creates a custom > PrintStream (SystemLogHandler) and replaces the default System.out and > System.err > > 2. logging classes start up and are initialized before the above said happens, > and at their initialization time they get reference to the original System.out > and System.err PrintStreams, bypassing this replacement trick. > > > After some thought my conclusion was that there is too much of a trick > involved in that swallowOutput thing and I would better seek for > a solution inside the logging framework itself. > > Though I do not have a clear recipe yet. I was not very interested. > > > Best regards, > Konstantin Kolinko > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
