[Bug 52092] Please make AsyncFileHandler and OneLineFormatter the default for logging.properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=52092 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Mark Thomas ma...@apache.org --- Fixed in trunk a.k.a. 8.0.x and will be included in 8.0.0-RC2 onwards. An added complication was correctly reporting the thread name when using the AsyncFileHandler. -- 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
DO NOT REPLY [Bug 52092] Please make AsyncFileHandler and OneLineFormatter the default for logging.properties
https://issues.apache.org/bugzilla/show_bug.cgi?id=52092 --- Comment #1 from Rainer Jung rainer.j...@kippdata.de 2011-10-26 14:16:35 UTC --- I'm +1 for TC 8 and +0 for TC 7 (not a clear +1 because of user compatibility reasons) Rainer -- 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
OneLineFormatter by default?
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? 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. Any comments? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: OneLineFormatter by default?
On 20/06/2011 15:51, Rainer Jung wrote: 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? 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. That might be a surprise for users. I'd lean towards make it the default via config (very easy to revert) and change the code default for 8.x onwards. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: OneLineFormatter by default?
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
Re: OneLineFormatter by default?
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
Re: OneLineFormatter by default?
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
Re: OneLineFormatter by default?
On 20.06.2011 20:10, Mark Thomas wrote: 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. Sorry for not having answered quicker: - you can use DateFormatCache like in the AccessLogValve: cachig is most efficient if done on a per second basis. Adding the milliseconds after the cached format is trivial and can be done after retrieving the format. - Yup, I have a variant ready, that copied a small DateFormatCache class into juli. I can post the patch in a few minutes, just want to test first. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: OneLineFormatter by default?
Mark, On 6/20/2011 10:54 AM, Mark Thomas wrote: On 20/06/2011 15:51, Rainer Jung wrote: 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? 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. That might be a surprise for users. +1 Though I also hate the timestamp\nmessage format, too, enough people probably rely on it to seriously break things. I'd lean towards make it the default via config (very easy to revert) and change the code default for 8.x onwards. +1 -chris signature.asc Description: OpenPGP digital signature
Re: OneLineFormatter by default?
On 20/06/2011 19:55, Rainer Jung wrote: On 20.06.2011 20:10, Mark Thomas wrote: 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. Sorry for not having answered quicker: - you can use DateFormatCache like in the AccessLogValve: cachig is most efficient if done on a per second basis. Adding the milliseconds after the cached format is trivial and can be done after retrieving the format. - Yup, I have a variant ready, that copied a small DateFormatCache class into juli. I can post the patch in a few minutes, just want to test first. Have at it :) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
