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. 33a Fax: 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
