Chris -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Tuesday, March 08, 2016 11:36 AM To: Tomcat Users List Subject: Re: Understanding how to controlling what data is written to log4j appenders
[SNIP] > 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. Ah, OK, interesting - thanks for explaining that. > 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. That's good to know and makes sense. > 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. Thanks, I did not know that. Might be handy if refactoring the application to replace System.out with logger calls is prohibitive. > 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. Ha, ha, ha! :-) -- Cris Berneburg, Lead Software Engineer, CACI
