-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cris,
On 3/8/16 11:16 AM, Cris Berneburg - US wrote: > Chris, > > -----Original Message----- From: Christopher Schultz > [mailto:ch...@christopherschultz.net] Sent: Tuesday, March 08, 2016 > 10:44 AM To: Tomcat Users List Subject: Re: Understanding how to > controlling what data is written to log4j appenders > > [SNIP] > >>> # stdout is set to be a ConsoleAppender. >>> log4j.appender.stdout=org.apache.log4j.ConsoleAppender >> >> This is what is killing you, plus everything that looks like >> this: >> >> log4j.logger.com.proginet.sift.struts=${cfi.struts.logging.level}, >> stdou t >> >> Everything that says log4j.logger.[something]=[level], stdout >> >> Is going to send those log messages to the "stdout" appender, >> which is tied to System.out. You'll need to do one of two things >> to dig yourself out: >> >> 1. Use swallowOutput="true" on your <Context>, which performs >> some magic to take System.out from applications' calls and >> redirect it elsewhere else (to the tomcat- defined loggers that >> can be configured in Tomcat's log4j.properties file). >> >> 2. Change the "stdout" appender to be something other than >> ConsoleAppender, and point it at a file on the disk. >> >> I'm not a fan of the first option, but it's sometimes the >> quickest way to handle everything all at once, and usually >> doesn't require any changes to the application's configuration. > > [SNIP] > >>> # Set root logger level to ERROR and its only appender to >>> stdout. log4j.rootLogger=ERROR, CFCC >>> >>> log4j.appender.CFCC = >>> org.apache.log4j.DailyRollingFileAppender >> >> That should probably work. >> >> But if you removed log4j.jar from the application, only the >> global log4j.properties file will be read. It's okay to have >> log4j.jar in the bin/ directory as well as your webapp's >> WEB-INF/lib directory. The former will run/configure Tomcat's >> logging, and the latter will run/configure the application's >> logging. In fact, if the application initializes log4j itself >> (usually by creating a new PropertyConfigurator object), then >> weird things can happen with the application re-defining the >> global configuration for Tomcat. >> >> I'd recommend having two .jar files and two .properties files, >> just to be safe. > > Thanks for taking the time to explain these 2 concepts. It has > helped me, and hopefully the question's originator, understand the > interaction between Tomcat and log4j a little better. Yeah, it's a shame it's the case, but to understand how logging works, you also have to understand how the logger configures itself (which isn't a big deal), and that also means understanding how Java ClassLoaders work. I didn't even say anything about ClassLoaders, but that's why this is all happening: when log4j is loaded, it only has visibility to the classes that have been loaded by its own ClassLoader or those "higher up" in the chain of ClassLoaders that go up to the initial ClassLoader that the JVM starts to load everything. You can even break the chain of ClassLoaders a bit if you want. For example, Tomcat uses its own bootstrap ClassLoader to load some very basic things, then loads the container in a separate ClassLoader so that it doesn't interfere with anything the web applications are doin g. Then each web application gets its own ClassLoader which doesn't have visibility into the server's ClassLoader. There are some games being played with which classes are and are not available to either (or both) Tomcat and the applications, much of which is not visible to the user unless they (a) understand it and (b) configure it differently from the default. The upshot is that, if you have your own log4j.jar file bundled with your application (which I think you *should*), then when you try to initialize it, it will initialize based upon the application's logging configuration and basically be completely separate from Tomcat's logging configuration. Then there is System.out, which is shared by everyone. So if your web application's logger is configure to log to System.out, then Tomcat's logger can capture that logging and *also* redirect it to wherever it wants. It's kind of like a river, where you can redirect the water almost wherever you want (except that this river can also clone water molecules and send them in two directions *at once*). Okay, terrible analogy. Sorry. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbe/2sACgkQ9CaO5/Lv0PCDFACgoMbWEU6jFVj4sfuw54I/61Ck WmMAn3ZbQOJQvPmvcu5wdY4zSFXS76Fw =q5s7 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
