I wanted to let you know that I really tried at this and feel the changes I made should be working and it is a matter of the developer hard coding the log messages to go to the stdout/stderr and became lazy as one of the other that commented had stated. I opened a ticket with the vendor but I have no idea how long it will take. So I went the route of writing a small perl script to copy the catalina.out file to a file with the same name and the date and time appended on the file name and then next I open the existing catalina.out file to clear the contents and then close it again to start the next day with a clean log file. It isn't the way I wanted to go but I ran out of time. If the vendor decides to work with me, it would be great but I have a feeling they will not go back and change things.
-Joleen On Tue, Mar 8, 2016 at 2:09 PM, Cris Berneburg - US <cberneb...@caci.com> wrote: > 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 > >
