Re: new log format?
Romain, On 7/28/14, 3:59 AM, Romain Manni-Bucau wrote: 2014-07-28 9:38 GMT+02:00 Rainer Jung rainer.j...@kippdata.de: Am 27.07.2014 um 19:19 schrieb Romain Manni-Bucau: Here is the one we use: http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/SingleLineFormatter.java Can you compare the infomration provided by that formatter withz the info provided by OneLineFormatter (Example line)? By a quick look at the code, OneLineFormatter doesn't seem to show much info. OneLineFormatter: 28-Jul-2014 09:56:25.516 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms SimpleLineFormatter: INFO - Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms Main difference is OneLineFormatter often overflow in console (font size 9pt, screen size: 17), not SimpleLineFormatter - very nice in dev I will be -1 to any change like you are suggesting. Word-wrapping is not something that a logger should do. When searching for errors in a log file, I don't want to have to grep for something and then go into the file to find out when it happened. The only thing that should be on separate lines is the stack trace if it's being included. If you want to look at a log file with certain portions cropped to a certain number of characters, use sed, awk, or cut. -chris signature.asc Description: OpenPGP digital signature
Re: new log format?
Actually i never said to use 2 lines. Just to not be that verbose for console (dev) logger. File layout should stay production compliant and onelineformatter is good for me even if truncating classes/method can be welcomed Le 30 juil. 2014 20:23, Christopher Schultz ch...@christopherschultz.net a écrit : Romain, On 7/28/14, 3:59 AM, Romain Manni-Bucau wrote: 2014-07-28 9:38 GMT+02:00 Rainer Jung rainer.j...@kippdata.de: Am 27.07.2014 um 19:19 schrieb Romain Manni-Bucau: Here is the one we use: http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/SingleLineFormatter.java Can you compare the infomration provided by that formatter withz the info provided by OneLineFormatter (Example line)? By a quick look at the code, OneLineFormatter doesn't seem to show much info. OneLineFormatter: 28-Jul-2014 09:56:25.516 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms SimpleLineFormatter: INFO - Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms Main difference is OneLineFormatter often overflow in console (font size 9pt, screen size: 17), not SimpleLineFormatter - very nice in dev I will be -1 to any change like you are suggesting. Word-wrapping is not something that a logger should do. When searching for errors in a log file, I don't want to have to grep for something and then go into the file to find out when it happened. The only thing that should be on separate lines is the stack trace if it's being included. If you want to look at a log file with certain portions cropped to a certain number of characters, use sed, awk, or cut. -chris
Re: new log format?
Romain, On 7/30/14, 3:52 PM, Romain Manni-Bucau wrote: Actually i never said to use 2 lines. Just to not be that verbose for console (dev) logger. File layout should stay production compliant and onelineformatter is good for me even if truncating classes/method can be welcomed I think if you want things to behave differently in development, then you should alter your development environment to behave that way. There's no need to change the stock Tomcat logger: it's easily replaced (edit logging.properties), or, if you wish, use the existing logger and massage your log files for viewing (e.g. sed/awk/cut). -chris Le 30 juil. 2014 20:23, Christopher Schultz ch...@christopherschultz.net a écrit : Romain, On 7/28/14, 3:59 AM, Romain Manni-Bucau wrote: 2014-07-28 9:38 GMT+02:00 Rainer Jung rainer.j...@kippdata.de: Am 27.07.2014 um 19:19 schrieb Romain Manni-Bucau: Here is the one we use: http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/SingleLineFormatter.java Can you compare the infomration provided by that formatter withz the info provided by OneLineFormatter (Example line)? By a quick look at the code, OneLineFormatter doesn't seem to show much info. OneLineFormatter: 28-Jul-2014 09:56:25.516 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms SimpleLineFormatter: INFO - Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms Main difference is OneLineFormatter often overflow in console (font size 9pt, screen size: 17), not SimpleLineFormatter - very nice in dev I will be -1 to any change like you are suggesting. Word-wrapping is not something that a logger should do. When searching for errors in a log file, I don't want to have to grep for something and then go into the file to find out when it happened. The only thing that should be on separate lines is the stack trace if it's being included. If you want to look at a log file with certain portions cropped to a certain number of characters, use sed, awk, or cut. -chris signature.asc Description: OpenPGP digital signature
Re: new log format?
Well it is easy (actually not since you need to hack classpath so a default log/*.jar in it would help) but the point is making it nice by default. Le 30 juil. 2014 21:59, Christopher Schultz ch...@christopherschultz.net a écrit : Romain, On 7/30/14, 3:52 PM, Romain Manni-Bucau wrote: Actually i never said to use 2 lines. Just to not be that verbose for console (dev) logger. File layout should stay production compliant and onelineformatter is good for me even if truncating classes/method can be welcomed I think if you want things to behave differently in development, then you should alter your development environment to behave that way. There's no need to change the stock Tomcat logger: it's easily replaced (edit logging.properties), or, if you wish, use the existing logger and massage your log files for viewing (e.g. sed/awk/cut). -chris Le 30 juil. 2014 20:23, Christopher Schultz ch...@christopherschultz.net a écrit : Romain, On 7/28/14, 3:59 AM, Romain Manni-Bucau wrote: 2014-07-28 9:38 GMT+02:00 Rainer Jung rainer.j...@kippdata.de: Am 27.07.2014 um 19:19 schrieb Romain Manni-Bucau: Here is the one we use: http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/SingleLineFormatter.java Can you compare the infomration provided by that formatter withz the info provided by OneLineFormatter (Example line)? By a quick look at the code, OneLineFormatter doesn't seem to show much info. OneLineFormatter: 28-Jul-2014 09:56:25.516 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms SimpleLineFormatter: INFO - Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms Main difference is OneLineFormatter often overflow in console (font size 9pt, screen size: 17), not SimpleLineFormatter - very nice in dev I will be -1 to any change like you are suggesting. Word-wrapping is not something that a logger should do. When searching for errors in a log file, I don't want to have to grep for something and then go into the file to find out when it happened. The only thing that should be on separate lines is the stack trace if it's being included. If you want to look at a log file with certain portions cropped to a certain number of characters, use sed, awk, or cut. -chris
Re: new log format?
Am 28.07.2014 um 09:59 schrieb Romain Manni-Bucau: 2014-07-28 9:38 GMT+02:00 Rainer Jung rainer.j...@kippdata.de: Am 27.07.2014 um 19:19 schrieb Romain Manni-Bucau: Here is the one we use: http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/SingleLineFormatter.java Can you compare the infomration provided by that formatter withz the info provided by OneLineFormatter (Example line)? By a quick look at the code, OneLineFormatter doesn't seem to show much info. OneLineFormatter: 28-Jul-2014 09:56:25.516 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms SimpleLineFormatter: INFO - Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms Main difference is OneLineFormatter often overflow in console (font size 9pt, screen size: 17), not SimpleLineFormatter - very nice in dev Main issue is logs are not redable with OneLineFormatter (nothing is aligned etc) which is sad since because it is the console logger it is the one used in dev. Readability is somewhat subjective. For a production use you'd typically not read a log file line by line from start to stop, but you are looking for patterns and then start to read lines around matches. But in order to be able to look for a pattern, context helps a lot. An important example is as Konstantin already mentioned the logging thread name. You can correlate with other logs and you can also untangle concurrent log events belonging to different threads/requests. I agree that's why having it in file logger is important but for console I think we can improve it (in particular since console logger is mainly the same as file logger with few less info so I consider it as a dev logger more than a prod one). OK, good thing: I myself would find it a good compromise to optimize the console handler by default on console use (dev), and the file handler on log file use (prod). That would mean they both need a different formatter (or formatter config is that is possible). Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new log format?
Am 27.07.2014 um 19:19 schrieb Romain Manni-Bucau: Here is the one we use: http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/SingleLineFormatter.java Can you compare the infomration provided by that formatter withz the info provided by OneLineFormatter (Example line)? By a quick look at the code, OneLineFormatter doesn't seem to show much info. Main issue is logs are not redable with OneLineFormatter (nothing is aligned etc) which is sad since because it is the console logger it is the one used in dev. Readability is somewhat subjective. For a production use you'd typically not read a log file line by line from start to stop, but you are looking for patterns and then start to read lines around matches. But in order to be able to look for a pattern, context helps a lot. An important example is as Konstantin already mentioned the logging thread name. You can correlate with other logs and you can also untangle concurrent log events belonging to different threads/requests. In IDE use, you might not need to much context, because you are already in a specific context when skimming through the log messages on the console. You'd also typically have small logs and very little concurrency. Tomcat for a long time was focusing with logging on dev use, no bundled dependencies, no fully-featured configurability, logs going to console by default etc. But the JVM default log format using two lines per message, one containing the time stamp and the other containing the message simply is crazy for real production. It was meant by Sun as example implementation for the formatter interface, but no one ever cared to provide production grade implementations. So I fully agree with Tomcat switching to OneLineFormatter. I think there is no optimal log config pleasing both dev and ops purposes. Of course both sides can optimize by changing the config but unfortunately that far from what happens most. We didn't change the logs go to console as well setting, we didn't include dependency on a fully blown log framework by default, but adding frequently needed log context was important (IHMO). I know you mostly want to only shorten some columns but personally I'm not a big fan of that. Regards, Rainer 2014-07-27 19:14 GMT+02:00 Konstantin Kolinko knst.koli...@gmail.com: 2014-07-24 21:15 GMT+04:00 Romain Manni-Bucau rmannibu...@gmail.com: Hi guys, just started to play with tomcat 8 and seems default log format changed (inline now) This doesn't seem that readable for me out of the box and wonder if we couldn't enhance default logging format to get a shorter and ligned log format (xx-yy-zz aa:bb [thread name on 15 chars max] [ class.method on 20chars max] message) Main point is to get everything aligned and not too wide The format is provided by formatter configured for a handler. Tomcat 7 by default uses java.util.logging.SimpleFormatter provided by JRE. Tomcat 8 by default uses our own org.apache.juli.OneLineFormatter There is no problem in implementing (and contributing) a different formatter if someone wants. I just do not see a point in mimicking the JRE one. The main benefit of OneLineFormatter for me is that it includes the thread name into the message. It allows to map it to thread names that may be logged by access log. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- kippdata informationstechnologie GmbH Tel: 0228 98549 -0 Bornheimer Str. 33aFax: 0228 98549 -50 53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new log format?
2014-07-28 9:38 GMT+02:00 Rainer Jung rainer.j...@kippdata.de: Am 27.07.2014 um 19:19 schrieb Romain Manni-Bucau: Here is the one we use: http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/SingleLineFormatter.java Can you compare the infomration provided by that formatter withz the info provided by OneLineFormatter (Example line)? By a quick look at the code, OneLineFormatter doesn't seem to show much info. OneLineFormatter: 28-Jul-2014 09:56:25.516 INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms SimpleLineFormatter: INFO - Deployment of web application archive /home/prod/hazelcast-tomcat/webapps/ROOT.war has finished in 3 283 ms Main difference is OneLineFormatter often overflow in console (font size 9pt, screen size: 17), not SimpleLineFormatter - very nice in dev Main issue is logs are not redable with OneLineFormatter (nothing is aligned etc) which is sad since because it is the console logger it is the one used in dev. Readability is somewhat subjective. For a production use you'd typically not read a log file line by line from start to stop, but you are looking for patterns and then start to read lines around matches. But in order to be able to look for a pattern, context helps a lot. An important example is as Konstantin already mentioned the logging thread name. You can correlate with other logs and you can also untangle concurrent log events belonging to different threads/requests. I agree that's why having it in file logger is important but for console I think we can improve it (in particular since console logger is mainly the same as file logger with few less info so I consider it as a dev logger more than a prod one). In IDE use, you might not need to much context, because you are already in a specific context when skimming through the log messages on the console. You'd also typically have small logs and very little concurrency. Tomcat for a long time was focusing with logging on dev use, no bundled dependencies, no fully-featured configurability, logs going to console by default etc. But the JVM default log format using two lines per message, one containing the time stamp and the other containing the message simply is crazy for real production. It was meant by Sun as example implementation for the formatter interface, but no one ever cared to provide production grade implementations. So I fully agree with Tomcat switching to OneLineFormatter. I think there is no optimal log config pleasing both dev and ops purposes. Of course both sides can optimize by changing the config but unfortunately that far from what happens most. We didn't change the logs go to console as well setting, we didn't include dependency on a fully blown log framework by default, but adding frequently needed log context was important (IHMO). I know you mostly want to only shorten some columns but personally I'm not a big fan of that. Regards, Rainer 2014-07-27 19:14 GMT+02:00 Konstantin Kolinko knst.koli...@gmail.com: 2014-07-24 21:15 GMT+04:00 Romain Manni-Bucau rmannibu...@gmail.com: Hi guys, just started to play with tomcat 8 and seems default log format changed (inline now) This doesn't seem that readable for me out of the box and wonder if we couldn't enhance default logging format to get a shorter and ligned log format (xx-yy-zz aa:bb [thread name on 15 chars max] [ class.method on 20chars max] message) Main point is to get everything aligned and not too wide The format is provided by formatter configured for a handler. Tomcat 7 by default uses java.util.logging.SimpleFormatter provided by JRE. Tomcat 8 by default uses our own org.apache.juli.OneLineFormatter There is no problem in implementing (and contributing) a different formatter if someone wants. I just do not see a point in mimicking the JRE one. The main benefit of OneLineFormatter for me is that it includes the thread name into the message. It allows to map it to thread names that may be logged by access log. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org -- kippdata informationstechnologie GmbH Tel: 0228 98549 -0 Bornheimer Str. 33aFax: 0228 98549 -50 53111 Bonn www.kippdata.de HRB 8018 Amtsgericht Bonn / USt.-IdNr. DE 196 457 417 Geschäftsführer: Dr. Thomas Höfer, Rainer Jung, Sven Maurmann -
Re: new log format?
2014-07-24 21:15 GMT+04:00 Romain Manni-Bucau rmannibu...@gmail.com: Hi guys, just started to play with tomcat 8 and seems default log format changed (inline now) This doesn't seem that readable for me out of the box and wonder if we couldn't enhance default logging format to get a shorter and ligned log format (xx-yy-zz aa:bb [thread name on 15 chars max] [ class.method on 20chars max] message) Main point is to get everything aligned and not too wide The format is provided by formatter configured for a handler. Tomcat 7 by default uses java.util.logging.SimpleFormatter provided by JRE. Tomcat 8 by default uses our own org.apache.juli.OneLineFormatter There is no problem in implementing (and contributing) a different formatter if someone wants. I just do not see a point in mimicking the JRE one. The main benefit of OneLineFormatter for me is that it includes the thread name into the message. It allows to map it to thread names that may be logged by access log. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new log format?
Here is the one we use: http://svn.apache.org/repos/asf/tomee/tomee/trunk/container/openejb-core/src/main/java/org/apache/openejb/log/SingleLineFormatter.java Main issue is logs are not redable with OneLineFormatter (nothing is aligned etc) which is sad since because it is the console logger it is the one used in dev. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-07-27 19:14 GMT+02:00 Konstantin Kolinko knst.koli...@gmail.com: 2014-07-24 21:15 GMT+04:00 Romain Manni-Bucau rmannibu...@gmail.com: Hi guys, just started to play with tomcat 8 and seems default log format changed (inline now) This doesn't seem that readable for me out of the box and wonder if we couldn't enhance default logging format to get a shorter and ligned log format (xx-yy-zz aa:bb [thread name on 15 chars max] [ class.method on 20chars max] message) Main point is to get everything aligned and not too wide The format is provided by formatter configured for a handler. Tomcat 7 by default uses java.util.logging.SimpleFormatter provided by JRE. Tomcat 8 by default uses our own org.apache.juli.OneLineFormatter There is no problem in implementing (and contributing) a different formatter if someone wants. I just do not see a point in mimicking the JRE one. The main benefit of OneLineFormatter for me is that it includes the thread name into the message. It allows to map it to thread names that may be logged by access log. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
new log format?
Hi guys, just started to play with tomcat 8 and seems default log format changed (inline now) This doesn't seem that readable for me out of the box and wonder if we couldn't enhance default logging format to get a shorter and ligned log format (xx-yy-zz aa:bb [thread name on 15 chars max] [ class.method on 20chars max] message) Main point is to get everything aligned and not too wide wdyt? Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau
DO NOT REPLY [Bug 49861] New: Log format of RMI ports can be improved, remove ,
https://issues.apache.org/bugzilla/show_bug.cgi?id=49861 Summary: Log format of RMI ports can be improved, remove , Product: Tomcat 6 Version: 6.0.29 Platform: PC OS/Version: Linux Status: NEW Severity: minor Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: p...@bieringer.de I've enabled the fixed JMX port listen capability described in http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html and found, that fixed ports are logged, but format is not proper imho: Is: INFO: The JMX Remote Listener has configured the registry on port 10,001 and the server on port 10,002 for the Platform server Should: INFO: The JMX Remote Listener has configured the registry on port 10001 and the server on port 10002 for the Platform server Just note that is very uncommon logging TCP/UDP ports with a , -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
