You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2011/06/20 16:51:22 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: OneLineFormatter by default?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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
Re: OneLineFormatter by default?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: OneLineFormatter by default?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: OneLineFormatter by default?
Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: OneLineFormatter by default?
Posted by Mark Thomas <ma...@apache.org>.
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 <ra...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: OneLineFormatter by default?
Posted by Rainer Jung <ra...@kippdata.de>.
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 <ra...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: OneLineFormatter by default?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/6/20 Rainer Jung <ra...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org