On 20/06/2011 19:07, Rainer Jung wrote: > Thanks Konstantin. I'll take a look at cleaning up 1) to 3), likely > using the DateFormatCache from the AccessLogValve as a utility class.
Already on it. Note DateFormatCache can't be used because a) JULI can't depend on Catalina and b) the AccessLog timestamps are accurate to the nearest second whereas the logging timestamps use ms. Mark > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
