RE: Understanding how to controlling what data is written to log4j appenders
This is great information to know. Our installations are on AIX boxes however. Joleen On Mar 10, 2016 10:31 PM, "George Stanchev" wrote: > If you run tomcat via the windows server wrapper, you can > > "%TOMCAT_EXE%" //US//%TOMCAT_SERVICE_NAME% --StdOutput > "%TOMCAT_CONSOLE_LOG%" --StdError "%TOMCAT_CONSOLE_LOG%" > > Which will redirect the stderr and stdoout to the corresponding log files > > George > > -Original Message- > From: Joleen Barker [mailto:oldenuf2no...@gmail.com] > Sent: Thursday, March 10, 2016 5:48 PM > To: Tomcat Users List > Subject: Re: Understanding how to controlling what data is written to > log4j appenders > > Thanks for the tips. I have to use the perl program for now to accomplish > the task for the company but l'll continue to work this for the sake of > learning and getting this changed through to application. > > Joleen > On Mar 10, 2016 7:42 PM, "Konstantin Kolinko" > wrote: > > > 2016-03-11 2:49 GMT+03:00 Joleen Barker : > > > 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. > > > > > > > On the logging page of the FAQ: > > https://wiki.apache.org/tomcat/FAQ/Logging#Q10 > > > > > > By the way, > > 1) It is possible to run with a debugger and put a breakpoint into > > java.io.PrintStream.println(String). I doubt that the PrintStream > > class is used much anywhere except to implement System.out/System.err. > > https://wiki.apache.org/tomcat/FAQ/Developing#Debugging > > > > 2) It is possible to search the class files for the message text. The > > classes store it in UTF-8, and jar files are just zip archives. > > > > > > > So are you suggesting to remove the ConsoleAppender from the > > > log4j.properties that the vendor has in the WEB-INF/classes directory? > > > > Yes. > > > > The same for Tomcat own log configuration, > > > > http://tomcat.apache.org/tomcat-8.0-doc/logging.html#Considerations_fo > > r_production_usage > > > > (Just mentioning for completeness. IIRC you have already reconfigured > > Tomcat own logging.) > > > > > > Best regards, > > Konstantin Kolinko > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > >
RE: Understanding how to controlling what data is written to log4j appenders
If you run tomcat via the windows server wrapper, you can "%TOMCAT_EXE%" //US//%TOMCAT_SERVICE_NAME% --StdOutput "%TOMCAT_CONSOLE_LOG%" --StdError "%TOMCAT_CONSOLE_LOG%" Which will redirect the stderr and stdoout to the corresponding log files George -Original Message- From: Joleen Barker [mailto:oldenuf2no...@gmail.com] Sent: Thursday, March 10, 2016 5:48 PM To: Tomcat Users List Subject: Re: Understanding how to controlling what data is written to log4j appenders Thanks for the tips. I have to use the perl program for now to accomplish the task for the company but l'll continue to work this for the sake of learning and getting this changed through to application. Joleen On Mar 10, 2016 7:42 PM, "Konstantin Kolinko" wrote: > 2016-03-11 2:49 GMT+03:00 Joleen Barker : > > 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. > > > > On the logging page of the FAQ: > https://wiki.apache.org/tomcat/FAQ/Logging#Q10 > > > By the way, > 1) It is possible to run with a debugger and put a breakpoint into > java.io.PrintStream.println(String). I doubt that the PrintStream > class is used much anywhere except to implement System.out/System.err. > https://wiki.apache.org/tomcat/FAQ/Developing#Debugging > > 2) It is possible to search the class files for the message text. The > classes store it in UTF-8, and jar files are just zip archives. > > > > So are you suggesting to remove the ConsoleAppender from the > > log4j.properties that the vendor has in the WEB-INF/classes directory? > > Yes. > > The same for Tomcat own log configuration, > > http://tomcat.apache.org/tomcat-8.0-doc/logging.html#Considerations_fo > r_production_usage > > (Just mentioning for completeness. IIRC you have already reconfigured > Tomcat own logging.) > > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Understanding how to controlling what data is written to log4j appenders
Thanks for the tips. I have to use the perl program for now to accomplish the task for the company but l'll continue to work this for the sake of learning and getting this changed through to application. Joleen On Mar 10, 2016 7:42 PM, "Konstantin Kolinko" wrote: > 2016-03-11 2:49 GMT+03:00 Joleen Barker : > > 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. > > > > On the logging page of the FAQ: > https://wiki.apache.org/tomcat/FAQ/Logging#Q10 > > > By the way, > 1) It is possible to run with a debugger and put a breakpoint into > java.io.PrintStream.println(String). I doubt that the PrintStream > class is used much anywhere except to implement System.out/System.err. > https://wiki.apache.org/tomcat/FAQ/Developing#Debugging > > 2) It is possible to search the class files for the message text. The > classes store it in UTF-8, and jar files are just zip archives. > > > > So are you suggesting to remove the ConsoleAppender from the > > log4j.properties that the vendor has in the WEB-INF/classes directory? > > Yes. > > The same for Tomcat own log configuration, > > http://tomcat.apache.org/tomcat-8.0-doc/logging.html#Considerations_for_production_usage > > (Just mentioning for completeness. IIRC you have already reconfigured > Tomcat own logging.) > > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Understanding how to controlling what data is written to log4j appenders
2016-03-11 2:49 GMT+03:00 Joleen Barker : > 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. > On the logging page of the FAQ: https://wiki.apache.org/tomcat/FAQ/Logging#Q10 By the way, 1) It is possible to run with a debugger and put a breakpoint into java.io.PrintStream.println(String). I doubt that the PrintStream class is used much anywhere except to implement System.out/System.err. https://wiki.apache.org/tomcat/FAQ/Developing#Debugging 2) It is possible to search the class files for the message text. The classes store it in UTF-8, and jar files are just zip archives. > So are you suggesting to remove the ConsoleAppender from the > log4j.properties that the vendor has in the WEB-INF/classes directory? Yes. The same for Tomcat own log configuration, http://tomcat.apache.org/tomcat-8.0-doc/logging.html#Considerations_for_production_usage (Just mentioning for completeness. IIRC you have already reconfigured Tomcat own logging.) Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Understanding how to controlling what data is written to log4j appenders
So are you suggesting to remove the ConsoleAppender from the log4j.properties that the vendor has in the WEB-INF/classes directory? Joleen On Mar 10, 2016 7:17 PM, "Konstantin Kolinko" wrote: > 2016-03-08 18:43 GMT+03:00 Christopher Schultz < > ch...@christopherschultz.net>: > > > > 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 , 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. > > The swallowOutput option is a remedy for direct System.out.println() > calls. One should not expect it to work with something that gets a > direct reference to System.out stream before Tomcat replaces it. > > For example, it Tomcat is reconfigured to use Log4J for its own > logging, and one configures a ConsoleAppender for Tomcat, this > ConsoleAppender is not affected by swallowOutput. > > The limitations are documented here: > > http://tomcat.apache.org/tomcat-8.0-doc/logging.html#Console > > If you do not want to log to stdout/stderr, you really must not > configure any ConsoleAppender,. > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Understanding how to controlling what data is written to log4j appenders
2016-03-08 18:43 GMT+03:00 Christopher Schultz : > > 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 , 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. The swallowOutput option is a remedy for direct System.out.println() calls. One should not expect it to work with something that gets a direct reference to System.out stream before Tomcat replaces it. For example, it Tomcat is reconfigured to use Log4J for its own logging, and one configures a ConsoleAppender for Tomcat, this ConsoleAppender is not affected by swallowOutput. The limitations are documented here: http://tomcat.apache.org/tomcat-8.0-doc/logging.html#Console If you do not want to log to stdout/stderr, you really must not configure any ConsoleAppender,. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Understanding how to controlling what data is written to log4j appenders
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 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 > >
RE: Understanding how to controlling what data is written to log4j appenders
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
Re: Understanding how to controlling what data is written to log4j appenders
Yes, I agree. I changed the file name in the default tomcat appender to be called tomcat and the one in the log4j file in the classes is called cfcc which makes more sense as that is the web applications context name. I'll keep plugging at it. I really thank you for your help. -Joleen On Tue, Mar 8, 2016 at 11:52 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Joleen, > > On 3/8/16 11:44 AM, Joleen Barker wrote: > > Hello Christopher, > > > > I thank you for your comments. I had changed the swallowOutput=true > > back when I changed the default tomcat logging to use the log4j > > properties files. I did rename the cfcc log I had to read tomcat > > and it comes up and captures the starting/stopping details but > > that's about it. There were a few other things but not many. I am > > not sure if you saw the 3rd log4j.properties set of details I > > placed in the email I sent with my configs. That held the changes I > > made to the vendors log4j. I left the CFCC appender in the classes > > log4j and changed the "stdout" to read CFCC and any logging that > > said "stdout" changed to CFCC. > > > > It was my hope that all the messages written would then go to my > > cfcc log but they didn't. I did see a few regarding SSH connections > > but that was all. The others are still going to the catalina.out. > > Remember that having two appenders to the same file is likely to cause > a problem. Especially if they are from two separate log4j.properties > files. > > You'll likely get two components opening the same file for writing. > Last one wins, and you'll get zero errors. > > > I will continue to work on this and test. > > > > If there is anything you think of and want to send it my way to try > > I will try it right away. > > > > I know that was very boring to read all that I posted. I thank > > everyone for their time. If I make progress and find the missing > > link I will send the results. > > Good luck. This stuff isn't always easy. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlbfA2AACgkQ9CaO5/Lv0PAATgCfRXXiwJk8AeeVycCZsAHJjTKu > uxIAmwWGQ180VdoFPxaadS33kik9xoe2 > =h5HR > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Understanding how to controlling what data is written to log4j appenders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joleen, On 3/8/16 11:44 AM, Joleen Barker wrote: > Hello Christopher, > > I thank you for your comments. I had changed the swallowOutput=true > back when I changed the default tomcat logging to use the log4j > properties files. I did rename the cfcc log I had to read tomcat > and it comes up and captures the starting/stopping details but > that's about it. There were a few other things but not many. I am > not sure if you saw the 3rd log4j.properties set of details I > placed in the email I sent with my configs. That held the changes I > made to the vendors log4j. I left the CFCC appender in the classes > log4j and changed the "stdout" to read CFCC and any logging that > said "stdout" changed to CFCC. > > It was my hope that all the messages written would then go to my > cfcc log but they didn't. I did see a few regarding SSH connections > but that was all. The others are still going to the catalina.out. Remember that having two appenders to the same file is likely to cause a problem. Especially if they are from two separate log4j.properties files. You'll likely get two components opening the same file for writing. Last one wins, and you'll get zero errors. > I will continue to work on this and test. > > If there is anything you think of and want to send it my way to try > I will try it right away. > > I know that was very boring to read all that I posted. I thank > everyone for their time. If I make progress and find the missing > link I will send the results. Good luck. This stuff isn't always easy. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbfA2AACgkQ9CaO5/Lv0PAATgCfRXXiwJk8AeeVycCZsAHJjTKu uxIAmwWGQ180VdoFPxaadS33kik9xoe2 =h5HR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Understanding how to controlling what data is written to log4j appenders
Hello Christopher, I thank you for your comments. I had changed the swallowOutput=true back when I changed the default tomcat logging to use the log4j properties files. I did rename the cfcc log I had to read tomcat and it comes up and captures the starting/stopping details but that's about it. There were a few other things but not many. I am not sure if you saw the 3rd log4j.properties set of details I placed in the email I sent with my configs. That held the changes I made to the vendors log4j. I left the CFCC appender in the classes log4j and changed the "stdout" to read CFCC and any logging that said "stdout" changed to CFCC. It was my hope that all the messages written would then go to my cfcc log but they didn't. I did see a few regarding SSH connections but that was all. The others are still going to the catalina.out. I will continue to work on this and test. If there is anything you think of and want to send it my way to try I will try it right away. I know that was very boring to read all that I posted. I thank everyone for their time. If I make progress and find the missing link I will send the results. -Joleen On Tue, Mar 8, 2016 at 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 , 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. > > -- > Cris Berneburg, Lead Software Engineer, CACI > >
Re: Understanding how to controlling what data is written to log4j appenders
-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 , 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
RE: Understanding how to controlling what data is written to log4j appenders
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 , 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. -- Cris Berneburg, Lead Software Engineer, CACI
Re: Understanding how to controlling what data is written to log4j appenders
On 08.03.2016 15:15, Joleen Barker wrote: Thank you for the idea. Worst case scenario, that is what I would have to do but I'm hoping someone that may have more experience than myself with be able to see that one thing I am missing. Another pair of eyes is always a good thing. Unfortunately Joleen, you are here encountering the typical "irresistible force against unmovable object" paradigm. Every programmer in the world suffers from hubris and laziness. Java and Tomcat programmers are no different. Logging is boring, and it is thus not something that the average program author thinks about very much or spends a lot of time on, until their supposedly perfect opus (here the hubris element) crashes badly, and they are at a loss to explain where or why. And when that happens, rather than going through the code again, and insert the simple and explicit logging statements which could have been there in the first place, they would much rather "delegate" the work to some outside agent, whose setup is preferably to be done by someone else (here the laziness element). And since this external logging agent has no idea of the logic of the piece of code it is supposed to log things about, perforce it has to be some quite complex opus itself, with a lot of cryptic configuration elements telling it where to insert itself, what to pick up and where to send it. Hence something like log4j (which is in itself an admirable piece of work, and may well be an opus of a magnitude and complexity similar to Tomcat, say. Ok, not quite; it's jar file is only about 1/3 the size of the Tomcat jars). So anyway, in the same way that no normal programmer really likes going through the code of someone else and attempting to understand it, not many people like to go through the log4j configuration file of someone else (which pretty much looks like its own programming language). So unless you find a really empathic soul here, it looks like you may now be pretty much on your own now, or to say this more canonically : the implementation details are left as an exercise to the reader. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Understanding how to controlling what data is written to log4j appenders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joleen, On 3/7/16 12:31 PM, Joleen Barker wrote: > The only thing I can think of to help you understand where I am at > is to post the different log4j.properties config files I have. So I > will post the one I have that went in for my default Tomcat > messages and is working fine. Perfect. > Updated log4j.properties file I now use in my CATALINA/lib > directory and is my base of my understanding for the changes I made > to the Vendor's log4j.properties file. > > My appender that rolls daily is CFCC and is getting most of what > was in the catalina.out log originally (this one I was happy > with): > > log4j.rootLogger = INFO, CATALINA This one looks fine. > Below this line is the Vendor's original one that was in the > /classes directory ( I also removed their > log4j-1.2.8-1.jar that was in the /lib directory folder as > it was older than the one I was using that is log4j-1.2.17.jar): (most of this is boring) > # Set root logger level to ERROR and its only appender to stdout. > log4j.rootLogger=ERROR, stdout Interesting, but only until: > # 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 , 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. > Below this line is my updated vendor log4j.properties file (I > really just added my CFCC appender information and changed anything > that read to use "stdout" since the log4j.rootLogger was set to > that to "CFCC" and then moved any logger and additivity to the > bottom of the file. But I'm thinking I may need to give the Tomcat > log4j CFCC appender a different file name to separate the > application log information from Tomcats log4j output that gets > written to the CFCC appender now. I also don't know what happens > to the rollover if the two arr referencing the same file name. I > was thinking it may roll over twice of something. What do you > think, can they both use the same one? I was trying to make it > similar to what happens in the product by default.) > > > # 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. > # stdout is set to be a ConsoleAppender. > log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender > log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout > log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [%t] > %-5p %c %x - %m%n The comment is wrong; the ConsuleAppender is called CONSOLE, not stdout. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbe8zIACgkQ9CaO5/Lv0PD6/gCfabK0eTyRhBgC/cNDj8fAV3L0 1csAniZXE2j9DPzqYg2vPEGs+KwzNegn =PKZ3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Understanding how to controlling what data is written to log4j appenders
Thank you for the idea. Worst case scenario, that is what I would have to do but I'm hoping someone that may have more experience than myself with be able to see that one thing I am missing. Another pair of eyes is always a good thing. -Joleen On Tue, Mar 8, 2016 at 8:39 AM, Cris Berneburg - US wrote: > Joleen > > >-Original Message- > >From: Joleen Barker [mailto:oldenuf2no...@gmail.com] > >Sent: Monday, March 07, 2016 3:54 PM > >To: Tomcat Users List > >Subject: Re: Understanding how to controlling what data is written to > log4j appenders > > > >One more thing I tried was to change the parent for the rootlogger from > CFCC to be CONSOLE to attempt to make it to where my log was not the parent > and it still didn't change it. I am getting 0 messages in my cfcc log and > everything still going to catalina.out. > > > >I know I'm so close to figuring out what little setting I am missing. > > > > > > > >On Mon, Mar 7, 2016 at 2:07 PM, Joleen Barker > >wrote: > > > >> There is a comment that says: > >> > >> #stdout is set to be a ConsoleAppender > >> > >> But I changed the "stdout" that was set as the parent to CFCC so I > >> thought then everything would go to the parent but I don't receive any > of the logs. > >> My cfcc log is just about empty except for the startup details. So I > >> went ahead and changed the CATALINABASE/lib log4j.properties file name > >> appender CFCC to go to a file named tomcat instead so I could > >> differentiate between the application logs and the tomcat logs. > >> > >> Now I get the startup messages in a log called tomcat (this is fine) > >> and not one message in my cfcc log. Even with my updated > >> log4j.properties file sitting in the WEB-INF/classes directory so I > >> must have something configured wrong that they are all still going to > >> the standard Stdout/Stderr. > >> > >> > >> > >> On Mon, Mar 7, 2016 at 12:54 PM, Joleen Barker > >> > >> wrote: > >> > >>> I forgot to tell Chuck that the swallowOutput parm is set to true in > >>> the context. When you see the vendor's log4j.properties you will see > >>> why there were so many messages still going to the catalina.out due > >>> to them using stdout. > >>> > >>> -Joleen > >>> > >>> On Mon, Mar 7, 2016 at 12:31 PM, Joleen Barker > >>> > >>> wrote: > >>> > >>>> Hello Christopher, Charles, and Cris, > >>>> > >>>> Thank you for all the responses. Thank you for the encouragement. I > >>>> dusted off my pants and went back at it. I made changes to the > >>>> Vendors log4j.properties file. When I really looked at it I was able > >>>> to determine they were things I was familiar with and the layout was > >>>> just throwing me off so I moved things around so the layout was > >>>> similar to the default log4j.properties I had. So I think I am > >>>> getting this a lot more. However, there are still some messages > >>>> going to the catalina.out. I think this will answer Chucks question > as to if the product was really using log4j. > >>>> > >>>> The only thing I can think of to help you understand where I am at > >>>> is to post the different log4j.properties config files I have. So I > >>>> will post the one I have that went in for my default Tomcat messages > and is working fine. > >>>> > >>>> Updated log4j.properties file I now use in my CATALINA/lib directory > >>>> and is my base of my understanding for the changes I made to the > >>>> Vendor's log4j.properties file. > >>>> > >>>> My appender that rolls daily is CFCC and is getting most of what was > >>>> in the catalina.out log originally (this one I was happy with): > > [SNIP] > > >>>> Below this line is my updated vendor log4j.properties file (I really > >>>> just added my CFCC appender information and changed anything that > >>>> read to use "stdout" since the log4j.rootLogger was set to that to > >>>> "CFCC" and then moved any logger and additivity to the bottom of the > >>>> file. But I'm thinking I may need to give the Tomcat log4j CFCC > >>>> appender a different file name to separate the application log > >>>>
RE: Understanding how to controlling what data is written to log4j appenders
Joleen >-Original Message- >From: Joleen Barker [mailto:oldenuf2no...@gmail.com] >Sent: Monday, March 07, 2016 3:54 PM >To: Tomcat Users List >Subject: Re: Understanding how to controlling what data is written to log4j >appenders > >One more thing I tried was to change the parent for the rootlogger from CFCC >to be CONSOLE to attempt to make it to where my log was not the parent and it >still didn't change it. I am getting 0 messages in my cfcc log and everything >still going to catalina.out. > >I know I'm so close to figuring out what little setting I am missing. > > > >On Mon, Mar 7, 2016 at 2:07 PM, Joleen Barker >wrote: > >> There is a comment that says: >> >> #stdout is set to be a ConsoleAppender >> >> But I changed the "stdout" that was set as the parent to CFCC so I >> thought then everything would go to the parent but I don't receive any of >> the logs. >> My cfcc log is just about empty except for the startup details. So I >> went ahead and changed the CATALINABASE/lib log4j.properties file name >> appender CFCC to go to a file named tomcat instead so I could >> differentiate between the application logs and the tomcat logs. >> >> Now I get the startup messages in a log called tomcat (this is fine) >> and not one message in my cfcc log. Even with my updated >> log4j.properties file sitting in the WEB-INF/classes directory so I >> must have something configured wrong that they are all still going to >> the standard Stdout/Stderr. >> >> >> >> On Mon, Mar 7, 2016 at 12:54 PM, Joleen Barker >> >> wrote: >> >>> I forgot to tell Chuck that the swallowOutput parm is set to true in >>> the context. When you see the vendor's log4j.properties you will see >>> why there were so many messages still going to the catalina.out due >>> to them using stdout. >>> >>> -Joleen >>> >>> On Mon, Mar 7, 2016 at 12:31 PM, Joleen Barker >>> >>> wrote: >>> >>>> Hello Christopher, Charles, and Cris, >>>> >>>> Thank you for all the responses. Thank you for the encouragement. I >>>> dusted off my pants and went back at it. I made changes to the >>>> Vendors log4j.properties file. When I really looked at it I was able >>>> to determine they were things I was familiar with and the layout was >>>> just throwing me off so I moved things around so the layout was >>>> similar to the default log4j.properties I had. So I think I am >>>> getting this a lot more. However, there are still some messages >>>> going to the catalina.out. I think this will answer Chucks question as to >>>> if the product was really using log4j. >>>> >>>> The only thing I can think of to help you understand where I am at >>>> is to post the different log4j.properties config files I have. So I >>>> will post the one I have that went in for my default Tomcat messages and >>>> is working fine. >>>> >>>> Updated log4j.properties file I now use in my CATALINA/lib directory >>>> and is my base of my understanding for the changes I made to the >>>> Vendor's log4j.properties file. >>>> >>>> My appender that rolls daily is CFCC and is getting most of what was >>>> in the catalina.out log originally (this one I was happy with): [SNIP] >>>> Below this line is my updated vendor log4j.properties file (I really >>>> just added my CFCC appender information and changed anything that >>>> read to use "stdout" since the log4j.rootLogger was set to that to >>>> "CFCC" and then moved any logger and additivity to the bottom of the >>>> file. But I'm thinking I may need to give the Tomcat log4j CFCC >>>> appender a different file name to separate the application log >>>> information from Tomcats log4j output that gets written to the CFCC >>>> appender now. I also don't know what happens to the rollover if the >>>> two arr referencing the same file name. I was thinking it may roll >>>> over twice of something. What do you think, can they both use the >>>> same one? I was trying to make it similar to what happens in the >>>> product by default.) [SNIP] >>>> I know, it's a lot to look at. Thank you for the help. Exactly what messages are in the default Tomcat logs that are not making it into the log4j logs? As I am new to l
Re: Understanding how to controlling what data is written to log4j appenders
>>> >>> # HCF variables >>> hcf.logging.level=ERROR >>> >>> # Optus variables >>> optus.logging.level=ERROR >>> >>> # SSO variables >>> sso.logging.level=ERROR >>> >>> # CFI variables >>> cfi.struts.logging.level=ERROR >>> >>> # Set root logger level to ERROR and its only appender to stdout. >>> log4j.rootLogger=ERROR, CFCC >>> >>> log4j.appender.CFCC = org.apache.log4j.DailyRollingFileAppender >>> log4j.appender.CFCC.File = ${catalina.base}/logs/cfcc >>> log4j.appender.CFCC.Append = true >>> log4j.appender.CFCC.Encoding = UTF-8 >>> log4j.appender.CFCC.DatePattern = '.'-MM-dd'.log' >>> log4j.appender.CFCC.layout = org.apache.log4j.PatternLayout >>> log4j.appender.CFCC.layout.ConversionPattern = %d [%t] %-5p %c- %m%n >>> >>> # stdout is set to be a ConsoleAppender. >>> log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender >>> log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout >>> log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [%t] %-5p %c >>> %x - %m%n >>> >>> # TradeLink is set to be a DailyRollingFileAppender. >>> log4j.appender.TradeLink=org.apache.log4j.DailyRollingFileAppender >>> log4j.appender.TradeLink.File=${cfi.trace.dir}/openbpm.html >>> log4j.appender.TradeLink.Append=true >>> log4j.appender.TradeLink.ImmediateFlush=true >>> log4j.appender.TradeLink.DatePattern='.'-MM-dd >>> log4j.appender.TradeLink.layout.Title=TradeLink >>> log4j.appender.TradeLink.layout=org.apache.log4j.HTMLLayout >>> log4j.appender.TradeLink.layout.ConversionPattern=%d{ISO8601} %-5p %c >>> %m%n >>> >>> # Crystal Reports is set to be a RollingFileAppender. >>> log4j.appender.jpeAppender=org.apache.log4j.RollingFileAppender >>> log4j.appender.jpeAppender.file=${crystal.logs.home}/jpe.log >>> log4j.appender.jpeAppender.ImmediateFlush=false >>> log4j.appender.jpeAppender.MaxBackupIndex=30 >>> log4j.appender.jpeAppender.MaxFileSize=500KB >>> log4j.appender.jpeAppender.layout=org.apache.log4j.PatternLayout >>> log4j.appender.jpeAppender.layout.ConversionPattern=%d{dd MMM >>> HH:mm:ss} [%t] %-5p %c - %m%n >>> >>> # RADIUS >>> log4j.logger.com.proginet.sift.login.RADIUSAuthMethod=ERROR, RADIUSFile >>> log4j.appender.RADIUSFile=org.apache.log4j.DailyRollingFileAppender >>> log4j.appender.RADIUSFile.File=${cfi.trace.dir}/RADIUS-trace.txt >>> log4j.appender.RADIUSFile.Append=true >>> log4j.appender.RADIUSFile.ImmediateFlush=true >>> log4j.appender.RADIUSFile.DatePattern='-'-MM-dd >>> log4j.appender.RADIUSFile.layout=org.apache.log4j.PatternLayout >>> log4j.appender.RADIUSFile.layout.ConversionPattern=%d{dd MMM >>> HH:mm:ss} [%t] %-5p %c - %m%n >>> >>> # Configure which loggers log to which appenders >>> log4j.logger.comp.user=${tradelink.logging.level}, TradeLink >>> log4j.logger.comp.tp=${tradelink.logging.level}, TradeLink >>> log4j.logger.comp.doc=${tradelink.logging.level}, TradeLink >>> log4j.logger.comp.bpm=${tradelink.logging.level}, TradeLink >>> log4j.logger.comp.agent=${tradelink.logging.level}, TradeLink >>> log4j.logger.comp.audit=${tradelink.logging.level}, TradeLink >>> log4j.logger.ArchiveAgent=${tradelink.logging.level}, TradeLink >>> log4j.logger.util=${tradelink.logging.level}, TradeLink >>> log4j.logger.lib=${tradelink.logging.level}, TradeLink >>> log4j.logger.com.crystaldecisions.reports=ERROR, jpeAppender >>> log4j.logger.com.crystaldecisions.threedg=ERROR, jpeAppender >>> log4j.logger.com.crystaldecisions.common=ERROR, jpeAppender >>> log4j.logger.com.proginet.sift.struts=${cfi.struts.logging.level}, CFCC >>> log4j.logger.com.proginet.siftssh=ERROR, CFCC >>> log4j.logger.com.proginet.siftftp.cert=ERROR, CFCC >>> log4j.logger.com.maverick=ERROR, CFCC >>> log4j.logger.com.sshtools=ERROR, CFCC >>> log4j.logger.com.proginet.sift.hcf=${hcf.logging.level}, CFCC >>> log4j.logger.com.proginet.sift.optus=${optus.logging.level}, CFCC >>> log4j.logger.com.proginet.sift.sso=${sso.logging.level}, CFCC >>> >>> # In order to prevent messages from being duplicated in the appenders >>> the additivity flag is >>> # needed to be set. What this does is prevent the child appenders from >>> also sending their >>> # messages to the parent appender which is the CFCC log. >>> log4j.additivity.comp.user=fa
Re: Understanding how to controlling what data is written to log4j appenders
der.TradeLink.layout.Title=TradeLink >> log4j.appender.TradeLink.layout=org.apache.log4j.HTMLLayout >> log4j.appender.TradeLink.layout.ConversionPattern=%d{ISO8601} %-5p %c %m%n >> >> # Crystal Reports is set to be a RollingFileAppender. >> log4j.appender.jpeAppender=org.apache.log4j.RollingFileAppender >> log4j.appender.jpeAppender.file=${crystal.logs.home}/jpe.log >> log4j.appender.jpeAppender.ImmediateFlush=false >> log4j.appender.jpeAppender.MaxBackupIndex=30 >> log4j.appender.jpeAppender.MaxFileSize=500KB >> log4j.appender.jpeAppender.layout=org.apache.log4j.PatternLayout >> log4j.appender.jpeAppender.layout.ConversionPattern=%d{dd MMM >> HH:mm:ss} [%t] %-5p %c - %m%n >> >> # RADIUS >> log4j.logger.com.proginet.sift.login.RADIUSAuthMethod=ERROR, RADIUSFile >> log4j.appender.RADIUSFile=org.apache.log4j.DailyRollingFileAppender >> log4j.appender.RADIUSFile.File=${cfi.trace.dir}/RADIUS-trace.txt >> log4j.appender.RADIUSFile.Append=true >> log4j.appender.RADIUSFile.ImmediateFlush=true >> log4j.appender.RADIUSFile.DatePattern='-'-MM-dd >> log4j.appender.RADIUSFile.layout=org.apache.log4j.PatternLayout >> log4j.appender.RADIUSFile.layout.ConversionPattern=%d{dd MMM >> HH:mm:ss} [%t] %-5p %c - %m%n >> >> # Configure which loggers log to which appenders >> log4j.logger.comp.user=${tradelink.logging.level}, TradeLink >> log4j.logger.comp.tp=${tradelink.logging.level}, TradeLink >> log4j.logger.comp.doc=${tradelink.logging.level}, TradeLink >> log4j.logger.comp.bpm=${tradelink.logging.level}, TradeLink >> log4j.logger.comp.agent=${tradelink.logging.level}, TradeLink >> log4j.logger.comp.audit=${tradelink.logging.level}, TradeLink >> log4j.logger.ArchiveAgent=${tradelink.logging.level}, TradeLink >> log4j.logger.util=${tradelink.logging.level}, TradeLink >> log4j.logger.lib=${tradelink.logging.level}, TradeLink >> log4j.logger.com.crystaldecisions.reports=ERROR, jpeAppender >> log4j.logger.com.crystaldecisions.threedg=ERROR, jpeAppender >> log4j.logger.com.crystaldecisions.common=ERROR, jpeAppender >> log4j.logger.com.proginet.sift.struts=${cfi.struts.logging.level}, CFCC >> log4j.logger.com.proginet.siftssh=ERROR, CFCC >> log4j.logger.com.proginet.siftftp.cert=ERROR, CFCC >> log4j.logger.com.maverick=ERROR, CFCC >> log4j.logger.com.sshtools=ERROR, CFCC >> log4j.logger.com.proginet.sift.hcf=${hcf.logging.level}, CFCC >> log4j.logger.com.proginet.sift.optus=${optus.logging.level}, CFCC >> log4j.logger.com.proginet.sift.sso=${sso.logging.level}, CFCC >> >> # In order to prevent messages from being duplicated in the appenders the >> additivity flag is >> # needed to be set. What this does is prevent the child appenders from >> also sending their >> # messages to the parent appender which is the CFCC log. >> log4j.additivity.comp.user=false >> log4j.additivity.comp.tp=false >> log4j.additivity.comp.doc=false >> log4j.additivity.comp.bpm=false >> log4j.additivity.comp.agent=false >> log4j.additivity.comp.audit=false >> log4j.additivity.ArchiveAgent=false >> log4j.additivity.util=false >> log4j.additivity.lib=false >> log4j.additivity.com.proginet.sift.struts=false >> log4j.additivity.com.proginet.siftssh=false >> log4j.additivity.com.proginet.siftftp.cert=false >> log4j.additivity.com.maverick=false >> log4j.additivity.com.sshtools=false >> log4j.additivity.com.proginet.sift.hcf=false >> log4j.additivity.com.proginet.sift.optus=false >> log4j.additivity.com.proginet.sift.sso=false >> >> >> I know, it's a lot to look at. Thank you for the help. >> >> -Joleen >> >> On Fri, Mar 4, 2016 at 4:33 PM, Cris Berneburg - US >> wrote: >> >>> Hi Joleen >>> >>> -Original Message- >>> From: Joleen Barker [mailto:oldenuf2no...@gmail.com] >>> Sent: Thursday, March 03, 2016 11:23 PM >>> To: Tomcat Users List >>> Subject: Re: Understanding how to controlling what data is written to >>> log4j appenders >>> >>> > Hello, >>> > >>> > I don't know if I should use a new thread or not but this is a >>> continuation of this issue. I found that even after my changes there was >>> very little being written to my new log and there were still many of the >>> product messages being written to the catalina.out. It has now come to my >>> attention that the web application contains a log4j.jar file in the >>> /lib directory and a log4j.properties file in the >>> /classes directory. >>> >
Re: Understanding how to controlling what data is written to log4j appenders
ons.threedg=ERROR, jpeAppender > log4j.logger.com.crystaldecisions.common=ERROR, jpeAppender > log4j.logger.com.proginet.sift.struts=${cfi.struts.logging.level}, CFCC > log4j.logger.com.proginet.siftssh=ERROR, CFCC > log4j.logger.com.proginet.siftftp.cert=ERROR, CFCC > log4j.logger.com.maverick=ERROR, CFCC > log4j.logger.com.sshtools=ERROR, CFCC > log4j.logger.com.proginet.sift.hcf=${hcf.logging.level}, CFCC > log4j.logger.com.proginet.sift.optus=${optus.logging.level}, CFCC > log4j.logger.com.proginet.sift.sso=${sso.logging.level}, CFCC > > # In order to prevent messages from being duplicated in the appenders the > additivity flag is > # needed to be set. What this does is prevent the child appenders from > also sending their > # messages to the parent appender which is the CFCC log. > log4j.additivity.comp.user=false > log4j.additivity.comp.tp=false > log4j.additivity.comp.doc=false > log4j.additivity.comp.bpm=false > log4j.additivity.comp.agent=false > log4j.additivity.comp.audit=false > log4j.additivity.ArchiveAgent=false > log4j.additivity.util=false > log4j.additivity.lib=false > log4j.additivity.com.proginet.sift.struts=false > log4j.additivity.com.proginet.siftssh=false > log4j.additivity.com.proginet.siftftp.cert=false > log4j.additivity.com.maverick=false > log4j.additivity.com.sshtools=false > log4j.additivity.com.proginet.sift.hcf=false > log4j.additivity.com.proginet.sift.optus=false > log4j.additivity.com.proginet.sift.sso=false > > > I know, it's a lot to look at. Thank you for the help. > > -Joleen > > On Fri, Mar 4, 2016 at 4:33 PM, Cris Berneburg - US > wrote: > >> Hi Joleen >> >> -Original Message- >> From: Joleen Barker [mailto:oldenuf2no...@gmail.com] >> Sent: Thursday, March 03, 2016 11:23 PM >> To: Tomcat Users List >> Subject: Re: Understanding how to controlling what data is written to >> log4j appenders >> >> > Hello, >> > >> > I don't know if I should use a new thread or not but this is a >> continuation of this issue. I found that even after my changes there was >> very little being written to my new log and there were still many of the >> product messages being written to the catalina.out. It has now come to my >> attention that the web application contains a log4j.jar file in the >> /lib directory and a log4j.properties file in the >> /classes directory. >> > This log4j.properties file has a lot more items in it and I believe is >> the reason all the messages from the product are still going to the >> catalina.out log. >> > >> > Here I was so proud of myself for getting the logs to go to an appender >> and the log rolling over as expected only to find the catalina.out still >> growing with messages from the application. >> >> Hey, that's a good start! I just completed refactoring our app to use >> log4j2, and it was a challenge. While I am new to using log4j, maybe we >> can stumble thru your problem and solve it together. >> >> > I am unsure how to get these messages to be added to my log file that >> is being used from the log4j.properties file that is in the >> CATALINA_BASE/lib directory. >> > >> > One of the other things I noticed is the vendor has a tomcat-juli.jar >> in the CATALINA_BASE/lib as well as in the CATALINA_BASE/bin directory >> where it should be. Would the one that is in the CATALINA_BASE/lib >> directory be doing anything. Maybe it is there in error and not really >> effecting anything but I don't know. >> > >> > I did read in a note on the tomcat web page that gave the instructions >> to use the log4j logging that the steps it had written were not needed if >> you just want to use log4j in your own web application - in that case, you >> would just put log4j and the log4j.properties in the WEB-INF/lib and the >> WEB-INF/classes of your web application which it appears the vendor did. So >> I think I would need to edit their log4j.properties file. >> > >> > Am I on the right track at all here? >> >> I would check a few things: >> >> 1. Check the container/application startup messages for autoconfig or >> default config notifications. This may be a moot point since you already >> said "the logs to go to an appender and the log rolling over as expected". >> >> 2. Check the log4j config files: >> a. For appenders that go to Console or System_Out. >> b. That the logger(s) refer to the appender(s) you want. >> c. Check the logger(s) "level" to ensure the messages levesl are >= >> that minim
Re: Understanding how to controlling what data is written to log4j appenders
eports variables crystal.logs.home=${user.home} # Tradelink variables tradelink.logging.level=ERROR # HCF variables hcf.logging.level=ERROR # Optus variables optus.logging.level=ERROR # SSO variables sso.logging.level=ERROR # CFI variables cfi.struts.logging.level=ERROR # Set root logger level to ERROR and its only appender to stdout. log4j.rootLogger=ERROR, CFCC log4j.appender.CFCC = org.apache.log4j.DailyRollingFileAppender log4j.appender.CFCC.File = ${catalina.base}/logs/cfcc log4j.appender.CFCC.Append = true log4j.appender.CFCC.Encoding = UTF-8 log4j.appender.CFCC.DatePattern = '.'-MM-dd'.log' log4j.appender.CFCC.layout = org.apache.log4j.PatternLayout log4j.appender.CFCC.layout.ConversionPattern = %d [%t] %-5p %c- %m%n # stdout is set to be a ConsoleAppender. log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout log4j.appender.CONSOLE.layout.ConversionPattern=%d{ISO8601} [%t] %-5p %c %x - %m%n # TradeLink is set to be a DailyRollingFileAppender. log4j.appender.TradeLink=org.apache.log4j.DailyRollingFileAppender log4j.appender.TradeLink.File=${cfi.trace.dir}/openbpm.html log4j.appender.TradeLink.Append=true log4j.appender.TradeLink.ImmediateFlush=true log4j.appender.TradeLink.DatePattern='.'-MM-dd log4j.appender.TradeLink.layout.Title=TradeLink log4j.appender.TradeLink.layout=org.apache.log4j.HTMLLayout log4j.appender.TradeLink.layout.ConversionPattern=%d{ISO8601} %-5p %c %m%n # Crystal Reports is set to be a RollingFileAppender. log4j.appender.jpeAppender=org.apache.log4j.RollingFileAppender log4j.appender.jpeAppender.file=${crystal.logs.home}/jpe.log log4j.appender.jpeAppender.ImmediateFlush=false log4j.appender.jpeAppender.MaxBackupIndex=30 log4j.appender.jpeAppender.MaxFileSize=500KB log4j.appender.jpeAppender.layout=org.apache.log4j.PatternLayout log4j.appender.jpeAppender.layout.ConversionPattern=%d{dd MMM HH:mm:ss} [%t] %-5p %c - %m%n # RADIUS log4j.logger.com.proginet.sift.login.RADIUSAuthMethod=ERROR, RADIUSFile log4j.appender.RADIUSFile=org.apache.log4j.DailyRollingFileAppender log4j.appender.RADIUSFile.File=${cfi.trace.dir}/RADIUS-trace.txt log4j.appender.RADIUSFile.Append=true log4j.appender.RADIUSFile.ImmediateFlush=true log4j.appender.RADIUSFile.DatePattern='-'-MM-dd log4j.appender.RADIUSFile.layout=org.apache.log4j.PatternLayout log4j.appender.RADIUSFile.layout.ConversionPattern=%d{dd MMM HH:mm:ss} [%t] %-5p %c - %m%n # Configure which loggers log to which appenders log4j.logger.comp.user=${tradelink.logging.level}, TradeLink log4j.logger.comp.tp=${tradelink.logging.level}, TradeLink log4j.logger.comp.doc=${tradelink.logging.level}, TradeLink log4j.logger.comp.bpm=${tradelink.logging.level}, TradeLink log4j.logger.comp.agent=${tradelink.logging.level}, TradeLink log4j.logger.comp.audit=${tradelink.logging.level}, TradeLink log4j.logger.ArchiveAgent=${tradelink.logging.level}, TradeLink log4j.logger.util=${tradelink.logging.level}, TradeLink log4j.logger.lib=${tradelink.logging.level}, TradeLink log4j.logger.com.crystaldecisions.reports=ERROR, jpeAppender log4j.logger.com.crystaldecisions.threedg=ERROR, jpeAppender log4j.logger.com.crystaldecisions.common=ERROR, jpeAppender log4j.logger.com.proginet.sift.struts=${cfi.struts.logging.level}, CFCC log4j.logger.com.proginet.siftssh=ERROR, CFCC log4j.logger.com.proginet.siftftp.cert=ERROR, CFCC log4j.logger.com.maverick=ERROR, CFCC log4j.logger.com.sshtools=ERROR, CFCC log4j.logger.com.proginet.sift.hcf=${hcf.logging.level}, CFCC log4j.logger.com.proginet.sift.optus=${optus.logging.level}, CFCC log4j.logger.com.proginet.sift.sso=${sso.logging.level}, CFCC # In order to prevent messages from being duplicated in the appenders the additivity flag is # needed to be set. What this does is prevent the child appenders from also sending their # messages to the parent appender which is the CFCC log. log4j.additivity.comp.user=false log4j.additivity.comp.tp=false log4j.additivity.comp.doc=false log4j.additivity.comp.bpm=false log4j.additivity.comp.agent=false log4j.additivity.comp.audit=false log4j.additivity.ArchiveAgent=false log4j.additivity.util=false log4j.additivity.lib=false log4j.additivity.com.proginet.sift.struts=false log4j.additivity.com.proginet.siftssh=false log4j.additivity.com.proginet.siftftp.cert=false log4j.additivity.com.maverick=false log4j.additivity.com.sshtools=false log4j.additivity.com.proginet.sift.hcf=false log4j.additivity.com.proginet.sift.optus=false log4j.additivity.com.proginet.sift.sso=false I know, it's a lot to look at. Thank you for the help. -Joleen On Fri, Mar 4, 2016 at 4:33 PM, Cris Berneburg - US wrote: > Hi Joleen > > -----Original Message----- > From: Joleen Barker [mailto:oldenuf2no...@gmail.com] > Sent: Thursday, March 03, 2016 11:23 PM > To: Tomcat Users List > Subject: Re: Understanding how to controlling what data is written to > log4j appenders >
RE: Understanding how to controlling what data is written to log4j appenders
Hi Joleen -Original Message- From: Joleen Barker [mailto:oldenuf2no...@gmail.com] Sent: Thursday, March 03, 2016 11:23 PM To: Tomcat Users List Subject: Re: Understanding how to controlling what data is written to log4j appenders > Hello, > > I don't know if I should use a new thread or not but this is a continuation > of this issue. I found that even after my changes there was very little being > written to my new log and there were still many of the product messages being > written to the catalina.out. It has now come to my attention that the web > application contains a log4j.jar file in the /lib directory and a > log4j.properties file in the /classes directory. > This log4j.properties file has a lot more items in it and I believe is the > reason all the messages from the product are still going to the catalina.out > log. > > Here I was so proud of myself for getting the logs to go to an appender and > the log rolling over as expected only to find the catalina.out still growing > with messages from the application. Hey, that's a good start! I just completed refactoring our app to use log4j2, and it was a challenge. While I am new to using log4j, maybe we can stumble thru your problem and solve it together. > I am unsure how to get these messages to be added to my log file that is > being used from the log4j.properties file that is in the CATALINA_BASE/lib > directory. > > One of the other things I noticed is the vendor has a tomcat-juli.jar in the > CATALINA_BASE/lib as well as in the CATALINA_BASE/bin directory where it > should be. Would the one that is in the CATALINA_BASE/lib directory be doing > anything. Maybe it is there in error and not really effecting anything but I > don't know. > > I did read in a note on the tomcat web page that gave the instructions to use > the log4j logging that the steps it had written were not needed if you just > want to use log4j in your own web application - in that case, you would just > put log4j and the log4j.properties in the WEB-INF/lib and the WEB-INF/classes > of your web application which it appears the vendor did. So I think I would > need to edit their log4j.properties file. > > Am I on the right track at all here? I would check a few things: 1. Check the container/application startup messages for autoconfig or default config notifications. This may be a moot point since you already said "the logs to go to an appender and the log rolling over as expected". 2. Check the log4j config files: a. For appenders that go to Console or System_Out. b. That the logger(s) refer to the appender(s) you want. c. Check the logger(s) "level" to ensure the messages levesl are >= that minimum threshold. 3. If you are in doubt as to which log4j config file is in use and have the ability to experiment, try changing the config files (and restarting the container?) to see how that affects the logs. Often what I will do is try to break something with invalid syntax - if that causes an error then I know I am editing the correct file, but if no error is generated, then I don't even have the correct file and know I should be looking elsewhere. 4. Check the application code to be sure it is not writing to System.out or calling exception printStackTrace directly. 5. Is there an "adaptor" for connecting the Tomcat logging interface to log4j that needs to be configured? I did not use the logging interface built into Tomcat, so I cannot provide help with that. > Would it be bad to post their log4j.properties along with mine to see how I > can edit it to have the info go to the new log? > > -Joleen > > On Fri, Dec 4, 2015 at 4:49 PM, Joleen Barker > wrote: > >> Hello Chris, >> >> As of now I am not using JULI any longer. I am using the log4j >> v1.2.17.jar >> >> Eventually I will jump in to the log4j v2 users and try my hand at that. >> >> Thank you for the clarification on where to go for information. I >> completely missed seeing the log4j mailing list. Could you send me the >> url to signup for it. >> >> Have a wonderful weekend. >> >> -Joleen >> >> >> >> On Fri, Dec 4, 2015 at 1:11 PM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >>> Joleen, >>> >>> On 12/3/15 11:55 PM, Joleen Barker wrote: >>>> The information you gave me for the additivity was PERFECT! It did >>> exactly >>>> what I was looking for. This also really allowed me to understand >>>> what processes were writing to which log. I have the settings in >>>> place in my test environment now and if all goes well the changes >>>> will be added
RE: Understanding how to controlling what data is written to log4j appenders
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: Understanding how to controlling what data is written to log4j > appenders > Can you confirm that the class in question is actually using log4j for > output? There's little that can be done if the class is using > System.out/System.err directly. Setting swallowOutput in the associated should help in such a situation. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Understanding how to controlling what data is written to log4j appenders
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joleen, On 3/3/16 11:23 PM, Joleen Barker wrote: > I don't know if I should use a new thread or not but this is a > continuation of this issue. Replying to this issue is entirely appropriate. > I found that even after my changes there was very little being > written to my new log and there were still many of the product > messages being written to the catalina.out. It has now come to my > attention that the web application contains a log4j.jar file in the > /lib directory and a log4j.properties file in the > /classes directory. This log4j.properties file has a lot > more items in it and I believe is the reason all the messages from > the product are still going to the catalina.out log. > > Here I was so proud of myself for getting the logs to go to an > appender and the log rolling over as expected only to find the > catalina.out still growing with messages from the application. > > I am unsure how to get these messages to be added to my log file > that is being used from the log4j.properties file that is in the > CATALINA_BASE/lib directory. Where is the class that is producing the log messages? Is it in the application, or has it been loaded by Tomcat because it's in CATALINA_BASE/lib, for example? Can you confirm that the class in question is actually using log4j for output? There's little that can be done if the class is using System.out/System.err directly. Also, does the log4j.properties file in the web application have any logging going to a ConsoleAppender? That's just the same as printing to System.out. > One of the other things I noticed is the vendor has a > tomcat-juli.jar in the CATALINA_BASE/lib as well as in the > CATALINA_BASE/bin directory where it should be. Would the one that > is in the CATALINA_BASE/lib directory be doing anything. Maybe it > is there in error and not really effecting anything but I don't > know. Tomcat will probably pick-up both JAR files, but the second one will be ignored, since the one in the bin/ directory will be preferred, and will be in the parent ClassLoader. Are those two .jar files identical? > I did read in a note on the tomcat web page that gave the > instructions to use the log4j logging that the steps it had written > were not needed if you just want to use log4j in your own web > application - in that case, you would just put log4j and the > log4j.properties in the WEB-INF/lib and the WEB-INF/classes of your > web application which it appears the vendor did. Right: the Tomcat configuration is only required if you want to use log4j for *Tomcat logging* instead of the standard JULI-based logging. > So I think I would need to edit their log4j.properties file. Possibly. As long as there is no use of ConsoleAppender in there (or catalina.out!), it should be fine. > Am I on the right track at all here? > > Would it be bad to post their log4j.properties along with mine to > see how I can edit it to have the info go to the new log? Just make sure to sanitize the configuration files. Make sure there aren't SMTP credentials or anything else in there. Also, you probably want to remove anything vendor-specific, such as thresholds for certain vendor-specific classes. Those don't really matter and also you want to protect the guilty. ;) - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlbZzlcACgkQ9CaO5/Lv0PA3QwCfXoVVcy6iq6uVnMDCEyLuOO40 w+8An3qB2/Z4q4R7YWMrRVGIEgHK1ASQ =q5Ob -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Understanding how to controlling what data is written to log4j appenders
Hello, I don't know if I should use a new thread or not but this is a continuation of this issue. I found that even after my changes there was very little being written to my new log and there were still many of the product messages being written to the catalina.out. It has now come to my attention that the web application contains a log4j.jar file in the /lib directory and a log4j.properties file in the /classes directory. This log4j.properties file has a lot more items in it and I believe is the reason all the messages from the product are still going to the catalina.out log. Here I was so proud of myself for getting the logs to go to an appender and the log rolling over as expected only to find the catalina.out still growing with messages from the application. I am unsure how to get these messages to be added to my log file that is being used from the log4j.properties file that is in the CATALINA_BASE/lib directory. One of the other things I noticed is the vendor has a tomcat-juli.jar in the CATALINA_BASE/lib as well as in the CATALINA_BASE/bin directory where it should be. Would the one that is in the CATALINA_BASE/lib directory be doing anything. Maybe it is there in error and not really effecting anything but I don't know. I did read in a note on the tomcat web page that gave the instructions to use the log4j logging that the steps it had written were not needed if you just want to use log4j in your own web application - in that case, you would just put log4j and the log4j.properties in the WEB-INF/lib and the WEB-INF/classes of your web application which it appears the vendor did. So I think I would need to edit their log4j.properties file. Am I on the right track at all here? Would it be bad to post their log4j.properties along with mine to see how I can edit it to have the info go to the new log? -Joleen On Fri, Dec 4, 2015 at 4:49 PM, Joleen Barker wrote: > Hello Chris, > > As of now I am not using JULI any longer. I am using the log4j v1.2.17.jar > > Eventually I will jump in to the log4j v2 users and try my hand at that. > > Thank you for the clarification on where to go for information. I > completely missed seeing the log4j mailing list. Could you send me the > url to signup for it. > > Have a wonderful weekend. > > -Joleen > > > > On Fri, Dec 4, 2015 at 1:11 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> Joleen, >> >> On 12/3/15 11:55 PM, Joleen Barker wrote: >> > The information you gave me for the additivity was PERFECT! It did >> exactly >> > what I was looking for. This also really allowed me to understand what >> > processes were writing to which log. I have the settings in place in my >> > test environment now and if all goes well the changes will be added in >> the >> > production environment soon. >> >> Glad you are making progress. >> >> There are many folks here who have experience with log4j (myself and, >> evidently, Konstantin as well), but for more thorough log4j help, you're >> probably going to wait to go over to the log4j mailing list. >> >> If JULI is in the mix (the default logging framework for Tomcat) and you >> are using logging.properties, then you want to stay /here/ for those >> questions. Similarly, for configuration involving Tomcat's >> container-defined loggers ("categories" in older log4j-speak), here is >> also the best place to post. >> >> -chris >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: Understanding how to controlling what data is written to log4j appenders
Hello Chris, As of now I am not using JULI any longer. I am using the log4j v1.2.17.jar Eventually I will jump in to the log4j v2 users and try my hand at that. Thank you for the clarification on where to go for information. I completely missed seeing the log4j mailing list. Could you send me the url to signup for it. Have a wonderful weekend. -Joleen On Fri, Dec 4, 2015 at 1:11 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > Joleen, > > On 12/3/15 11:55 PM, Joleen Barker wrote: > > The information you gave me for the additivity was PERFECT! It did > exactly > > what I was looking for. This also really allowed me to understand what > > processes were writing to which log. I have the settings in place in my > > test environment now and if all goes well the changes will be added in > the > > production environment soon. > > Glad you are making progress. > > There are many folks here who have experience with log4j (myself and, > evidently, Konstantin as well), but for more thorough log4j help, you're > probably going to wait to go over to the log4j mailing list. > > If JULI is in the mix (the default logging framework for Tomcat) and you > are using logging.properties, then you want to stay /here/ for those > questions. Similarly, for configuration involving Tomcat's > container-defined loggers ("categories" in older log4j-speak), here is > also the best place to post. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Understanding how to controlling what data is written to log4j appenders
Joleen, On 12/3/15 11:55 PM, Joleen Barker wrote: > The information you gave me for the additivity was PERFECT! It did exactly > what I was looking for. This also really allowed me to understand what > processes were writing to which log. I have the settings in place in my > test environment now and if all goes well the changes will be added in the > production environment soon. Glad you are making progress. There are many folks here who have experience with log4j (myself and, evidently, Konstantin as well), but for more thorough log4j help, you're probably going to wait to go over to the log4j mailing list. If JULI is in the mix (the default logging framework for Tomcat) and you are using logging.properties, then you want to stay /here/ for those questions. Similarly, for configuration involving Tomcat's container-defined loggers ("categories" in older log4j-speak), here is also the best place to post. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Understanding how to controlling what data is written to log4j appenders
Konstantin, The information you gave me for the additivity was PERFECT! It did exactly what I was looking for. This also really allowed me to understand what processes were writing to which log. I have the settings in place in my test environment now and if all goes well the changes will be added in the production environment soon. Thank you. On Thu, Dec 3, 2015 at 9:42 PM, Joleen Barker wrote: > Hello Konstantin, > > Thank you for pointing out the typo. The line is actually correct in my > log4j.properties file and the typo happened when I typed the line in for my > settings. > > I don't know what additivity flag is so I will take a look. > > I'll let you know how it goes. > > -Joleen > > On Thu, Dec 3, 2015 at 7:53 PM, Konstantin Kolinko > wrote: > >> 2015-12-04 2:05 GMT+03:00 Joleen Barker : >> > I want to have more control over what data is written to the various >> > appenders in the log4j.properties files. I have played around with the >> > various configurations in the log4j.properties file but I am not >> > understanding how they are working in order to grasp how to have more >> > control. I don't know if it would be a matter of turning off the INFO >> > setting for the log4j.rootLogger and somehow setting individual logging >> for >> > each appender. >> > >> > Below is my environment details: >> > 1) The tomcat version that is running is v8.0.26.0 >> > 2) The OS is a Centos v7 UNIX VM >> > 3) Java JDK I have installed that Tomcat is using is 1.8.0_60 >> > 4) Due to the catalina.out file growing too large with the default >> > juli.AsyncFileHandler using the logging.properties file that was found >> in >> > the $CATALINA_HOME/conf directory. I changed the settings on a vendors >> > software to use the log4j logging instead. (So this is NOT my web >> > application or product written by me.) >> >> None of AsyncFileHandler is responsible for catalina.out. >> >> The catalina.out file consumes output of ConsoleHandler. >> >> > >> > >> log4j;logger.org.apache.catalina.core,ContainerBase.[Catalina].[localhost].[/cfcc]=INFO, >> CFCC >> > >> >> The above line has a typo. s/;/./ after "log4j" >> >> > <...> >> >> >> You need to set "additivity" flag for non-root loggers to false. >> I have not tested, but I think it will be like this: >> >> >> >> log4j.additivity.org.apache.catalina.core,ContainerBase.[Catalina].[localhost].[/cfcc]=false >> >> log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=false >> >> log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager]=false >> >> log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager]=false >> >> >> >> Documentation for Log4j 1.x: >> [1] http://logging.apache.org/log4j/1.2/ >> >> Guide: >> [2] http://logging.apache.org/log4j/1.2/manual.html >> >> Syntax of log4j.properties file: >> [3] >> http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html#doConfigure%28java.lang.String,%20org.apache.log4j.spi.LoggerRepository%29 >> >> Best regards, >> Konstantin Kolinko >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >
Re: Understanding how to controlling what data is written to log4j appenders
Hello Konstantin, Thank you for pointing out the typo. The line is actually correct in my log4j.properties file and the typo happened when I typed the line in for my settings. I don't know what additivity flag is so I will take a look. I'll let you know how it goes. -Joleen On Thu, Dec 3, 2015 at 7:53 PM, Konstantin Kolinko wrote: > 2015-12-04 2:05 GMT+03:00 Joleen Barker : > > I want to have more control over what data is written to the various > > appenders in the log4j.properties files. I have played around with the > > various configurations in the log4j.properties file but I am not > > understanding how they are working in order to grasp how to have more > > control. I don't know if it would be a matter of turning off the INFO > > setting for the log4j.rootLogger and somehow setting individual logging > for > > each appender. > > > > Below is my environment details: > > 1) The tomcat version that is running is v8.0.26.0 > > 2) The OS is a Centos v7 UNIX VM > > 3) Java JDK I have installed that Tomcat is using is 1.8.0_60 > > 4) Due to the catalina.out file growing too large with the default > > juli.AsyncFileHandler using the logging.properties file that was found in > > the $CATALINA_HOME/conf directory. I changed the settings on a vendors > > software to use the log4j logging instead. (So this is NOT my web > > application or product written by me.) > > None of AsyncFileHandler is responsible for catalina.out. > > The catalina.out file consumes output of ConsoleHandler. > > > > > > log4j;logger.org.apache.catalina.core,ContainerBase.[Catalina].[localhost].[/cfcc]=INFO, > CFCC > > > > The above line has a typo. s/;/./ after "log4j" > > > <...> > > > You need to set "additivity" flag for non-root loggers to false. > I have not tested, but I think it will be like this: > > > > log4j.additivity.org.apache.catalina.core,ContainerBase.[Catalina].[localhost].[/cfcc]=false > > log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=false > > log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager]=false > > log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager]=false > > > > Documentation for Log4j 1.x: > [1] http://logging.apache.org/log4j/1.2/ > > Guide: > [2] http://logging.apache.org/log4j/1.2/manual.html > > Syntax of log4j.properties file: > [3] > http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html#doConfigure%28java.lang.String,%20org.apache.log4j.spi.LoggerRepository%29 > > Best regards, > Konstantin Kolinko > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Understanding how to controlling what data is written to log4j appenders
2015-12-04 2:05 GMT+03:00 Joleen Barker : > I want to have more control over what data is written to the various > appenders in the log4j.properties files. I have played around with the > various configurations in the log4j.properties file but I am not > understanding how they are working in order to grasp how to have more > control. I don't know if it would be a matter of turning off the INFO > setting for the log4j.rootLogger and somehow setting individual logging for > each appender. > > Below is my environment details: > 1) The tomcat version that is running is v8.0.26.0 > 2) The OS is a Centos v7 UNIX VM > 3) Java JDK I have installed that Tomcat is using is 1.8.0_60 > 4) Due to the catalina.out file growing too large with the default > juli.AsyncFileHandler using the logging.properties file that was found in > the $CATALINA_HOME/conf directory. I changed the settings on a vendors > software to use the log4j logging instead. (So this is NOT my web > application or product written by me.) None of AsyncFileHandler is responsible for catalina.out. The catalina.out file consumes output of ConsoleHandler. > > log4j;logger.org.apache.catalina.core,ContainerBase.[Catalina].[localhost].[/cfcc]=INFO, CFCC > The above line has a typo. s/;/./ after "log4j" > <...> You need to set "additivity" flag for non-root loggers to false. I have not tested, but I think it will be like this: log4j.additivity.org.apache.catalina.core,ContainerBase.[Catalina].[localhost].[/cfcc]=false log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=false log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager]=false log4j.additivity.org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager]=false Documentation for Log4j 1.x: [1] http://logging.apache.org/log4j/1.2/ Guide: [2] http://logging.apache.org/log4j/1.2/manual.html Syntax of log4j.properties file: [3] http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PropertyConfigurator.html#doConfigure%28java.lang.String,%20org.apache.log4j.spi.LoggerRepository%29 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org