Thanks Konstantin. I'll take a look at cleaning up 1) to 3), likely using the DateFormatCache from the AccessLogValve as a utility class.
Regards, Rainer On 20.06.2011 18:52, Konstantin Kolinko wrote: > 2011/6/20 Rainer Jung <rainer.j...@kippdata.de>: >> Should we use the new OneLineFormatter as the default juli formatter? >> >> I never found anyone who liked the default java.util.logging log format, >> which spreads all messages out via two lines. One line contains the >> timestamp, the other line the message. >> >> So if your grep for a message, you want find out when it was issued, and >> if you look for a certain time range, yout wont see the actual messages. >> Non-sense. >> >> Now that we have our nice little OneLineFormatter, why not use it as >> default? >> > > I like the default SimpleFormatter. With the SimpleFormatter those > messages fit better when they are printed into console window. It is > easier to read through the log files as well. > > With OneLineFormatter the messages are shifted to the right. The > offset is arbitrary, because class names before the message have > arbitrary length. Enabling line wrapping in file viewer is possible, > but does not make those lines more readable. It is hard to read. > > I think SimpleFormatter should stay as the default. > > > Some nitpicks looking at the source code of OneLineFormatter. > > 1) OneLineFormatter#currentDate and currentDateString are used in > double locking. If I understand it correctly, the should be made > volatile. Though see the next point. > > 2) I do not understand why OneLineFormatter#addTimestamp( ) method is public. > > It could be protected. It is not used anywhere else. Furthermore, the > only place where it is called, the #format() method, always creates a > new instance of Date object. Thus "if (currentDate != date)" > comparison of object instances does not make sense. > > 3) msec value looses its leading zero. E.g. in two subsequent lines: > > 20-Jun-2011 20:25:25.46 > 20-Jun-2011 20:25:25.531 > > 4) SimpleFormatter#format() delegates message formatting to > Formatter#formatMessage(..) which performs lookup through a resource > bundle and does formatting of parameters. > > OneLineFormatter does not do it. It just uses the message as String. > It is not of much difference for Tomcat, because Tomcat does not use > java.util.logging directly, but some other webapps may use it. > (Not a very strong argument though). > >> If we use it as default: should be have it as default without config, >> i.e. as a default in code, or do we want to add the .formatter lines to >> our loggging.properties? Or add the formatter system property to >> catalina.properties? >> >> I think I would favor having it as a code default, i.e. without any >> configuration. >> > > In the code you can change default for the JULI's FileHandler only. > (Unless you tweak properties loading itself). There are other Handler > implementations there. > > If it were changed I'd prefer it to be in the configuration. > > > Regarding grep: > Some grep implementations (e.g. the GNU one) have > --context, --before-context, --after-context options to print several lines > of context for each match > (section 2.1.5 in [1]). > > [1]: http://www.gnu.org/software/grep/manual/ > > Best regards, > Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
