You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by David Blevins <da...@visi.com> on 2007/08/01 04:47:10 UTC
Re: Juli/Logging
On Jul 31, 2007, at 2:27 PM, Rainer Jung wrote:
> Hi David,
>
> our default bundled JULI only has a binding for java.util.logging. On
>
> http://tomcat.apache.org/tomcat-6.0-doc/extras.html
>
> there is a very short description, how one builds a JULI, that is
> log4j enabled. The static binding was chosen, because commons-
> logging auto detection provided to many problems w.r.t.
> redeployment and classloader leaks.
Cool, thanks.
> My personal opinion: java.util.logging very much lacks a good
> formatter. The default 2 line formatting of messages, splitting
> timestamps and message in separate lines, is not really useful in
> production. Many ad hoc log analysis practices work on a line
> oriented basis.
Was wondering about that. I've heard people grumble about
java.util.logging, but haven't (till now) heard anything specific.
Maybe I wasn't paying close enough attention, but the Tomcat 6 log
files still seem to follow the one line per message format. How did
you pull that off?
-David
>
> Regards,
>
> Rainer
>
> David Blevins wrote:
>> So another topic,
>> There's a thread going on in OpenEJB at the moment about possibly
>> switching away from log4j for the reason that the logging config
>> gets easily messed up in embedded environments (maven,
>> specificaly) and of course to have one less dependency -- the 3.0
>> server is a bit beefier than the 1.0.
>> I remembered not seeing log4j or commons logging in Tomcat 6 and
>> started investigating -- how I discovered the inlining. Seems
>> juli is a trimmed down version of commons-logging (attractive),
>> but it isn't obvious what's driving the actual logging. Didn't
>> see any inlined log4j classes. Are you using java.util.Logging or
>> something else?
>> Also noticed the javadoc of juli says it allows for per-
>> classloader configuration of logging. What exactly does that mean?
>> Thanks!
>> -David
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@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
> ===============================
> kippdata
> informationstechnologie GmbH Tel: +49 228 98549 -0
> Bornheimer Str. 33a Fax: +49 228 98549 -50
> D-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-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: Juli/Logging
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Remy,
if we only want to give an alternative for the SimpleFormatter:
that one is not configurable, so it's capabilities are printing out a
localized timestamp, after that the class and method, a localized level
string, and last the log message. All of those are basically given by
the log record, level localization is provided by the Level class,
Timestamp is not problem (milliseconds in the log record), and should
also contain the millisesond fraction.
Of course we could add configurability in a next step, which would
basically mean an accesslog/log4j like pattern string for the log line.
The log record carries the following information:
- level
- message
- milliseconds timestamp
- source class and method name
- thread id
- logger name
- sequence number (interesting feature, so one can easily describe,
which message instance in a log one is talking about)
and more complex objects
- thrown (throwable associated with the record)
- resource bundle and/or resource bundle name to format message string
- parameters, log data extension
The simple objects could be configured by a simple pattern character,
the more complex ones need more thought :)
I think already the direct simpleformatter replacement, even without
configurability would be an improvement!
If that formatter would work with j.u.l. i.e. without juli, I would love
it even more. The configurability of course might add a slight
dependency to juli (where do we get the parameters from, i.e. how do we
pass the information from logging.properties to the formatter). Not
really a dependency, but probably additional setters that are called by
juli, and when using the formatter in j.u.l one would have to write the
code that calls the setters oneself (or use juli).
Regards,
Rainer
Remy Maucherat wrote:
> Rainer Jung wrote:
>> That's why it would be nice if someone took the burden of writing a
>> better log formatter for j.u.l.
>
> What should it look like ?
>
> Rémy
Object[] getParameters()
Get the parameters to the log message.
ResourceBundle getResourceBundle()
Get the localization resource bundle
String getResourceBundleName()
Get the localization resource bundle name
long getSequenceNumber()
Get the sequence number.
Throwable getThrown()
Get any throwable associated with the log record.
void setParameters(Object[] parameters)
Set the parameters to the log message.
void setResourceBundle(ResourceBundle bundle)
Set the localization resource bundle.
void setResourceBundleName(String name)
Set the localization resource bundle name.
void setSequenceNumber(long seq)
Set the sequence number.
void setThrown(Throwable thrown)
Set a throwable associated with the log event.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Juli/Logging
Posted by Rainer Jung <ra...@kippdata.de>.
Forget the previous post, it contained garbage at the end
Hi Remy,
if we only want to give an alternative for the SimpleFormatter:
that one is not configurable, so it's capabilities are printing out a
localized timestamp, after that the class and method, a localized level
string, and last the log message. All of those are basically given by
the log record, level localization is provided by the Level class,
Timestamp is not problem (milliseconds in the log record), and should
also contain the millisesond fraction.
Of course we could add configurability in a next step, which would
basically mean an accesslog/log4j like pattern string for the log line.
The log record carries the following information:
- level
- message
- milliseconds timestamp
- source class and method name
- thread id
- logger name
- sequence number (interesting feature, so one can easily describe,
which message instance in a log one is talking about)
and more complex objects
- thrown (throwable associated with the record)
- resource bundle and/or resource bundle name to format message string
- parameters, log data extension
The simple objects could be configured by a simple pattern character,
the more complex ones need more thought :)
I think already the direct simpleformatter replacement, even without
configurability would be an improvement!
If that formatter would work with j.u.l. i.e. without juli, I would love
it even more. The configurability of course might add a slight
dependency to juli (where do we get the parameters from, i.e. how do we
pass the information from logging.properties to the formatter). Not
really a dependency, but probably additional setters that are called by
juli, and when using the formatter in j.u.l one would have to write the
code that calls the setters oneself (or use juli).
Regards,
Rainer
Remy Maucherat wrote:
> Rainer Jung wrote:
>> That's why it would be nice if someone took the burden of writing a
>> better log formatter for j.u.l.
>
> What should it look like ?
>
> Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Juli/Logging
Posted by Remy Maucherat <re...@apache.org>.
Rainer Jung wrote:
> That's why it would be nice if someone took the burden of writing a
> better log formatter for j.u.l.
What should it look like ?
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Juli/Logging
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> I think something is missing - DirectJDKLog is looking for a
> JdkLoggerFormatter that would do
> the trick. I may have forgot to add it, I have it on my machine ( I hate too
> the default format ).
> There's also a config override allowing default properties to be loaded from
> a different location.
I don't think I removed those two classes, so feel free to add them. You
don't need to hardcode configuration, the LogManager that replaces the
default one supports a lot of stuff.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Juli/Logging
Posted by Remy Maucherat <re...@apache.org>.
Costin Manolache wrote:
> Can be changed to include a better date format.
>
> I used this to look at execution times and start time - so millis was quite
> nice. Also more
> efficient to generate.
Ideally, it would use a pattern property to configure it, like:
logger_prefix.org.apache.juli.PatternFormatter.pattern
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Juli/Logging
Posted by Costin Manolache <co...@gmail.com>.
Can be changed to include a better date format.
I used this to look at execution times and start time - so millis was quite
nice. Also more
efficient to generate.
Costin
On 8/2/07, Rainer Jung <ra...@kippdata.de> wrote:
>
> Hi Costin (and Remy),
>
> I had a quick look at the JdkLoggerFormatter (found in an old revision
> of the sandbox, it's not there any more):
>
> this formatter uses a *very* compact format. E.g. the timestamp is just
> the milliseconds and the log level is abbreviated with a single
> character. Although technically very useful, I doubt that most admins
> will like it at first sight, so it might not be a good default
> replacement for the JDK simple formatter. Still searching ...
>
> Regards,
>
> Rainer
>
> Costin Manolache wrote:
> > I think something is missing - DirectJDKLog is looking for a
> > JdkLoggerFormatter that would do
> > the trick. I may have forgot to add it, I have it on my machine ( I hate
> too
> > the default format ).
> > There's also a config override allowing default properties to be loaded
> from
> > a different location.
> >
> > Costin
> >
> > On 8/2/07, Remy Maucherat <re...@apache.org> wrote:
> >> Rainer Jung wrote:
> >>>>> That's why it would be nice if someone took the burden of writing a
> >>>>> better log formatter for j.u.l.
> >>>> Got it. Yea, that format is certainly grep unfriendly.
> >>>>
> >>>> Looks like Harmony has a formatter we could copy from and fix to not
> >>>> add the new line.
> >>>>
> >>>>
> >>
> http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java
> >>> Yes, that could be a good starting point (although that implementation
> >>> does not care about localization).
> >> It might be better to use log4j code as a starting point as it already
> >> has the pattern processing code.
> >>
> >> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Juli/Logging
Posted by Rainer Jung <ra...@kippdata.de>.
Hi Costin (and Remy),
I had a quick look at the JdkLoggerFormatter (found in an old revision
of the sandbox, it's not there any more):
this formatter uses a *very* compact format. E.g. the timestamp is just
the milliseconds and the log level is abbreviated with a single
character. Although technically very useful, I doubt that most admins
will like it at first sight, so it might not be a good default
replacement for the JDK simple formatter. Still searching ...
Regards,
Rainer
Costin Manolache wrote:
> I think something is missing - DirectJDKLog is looking for a
> JdkLoggerFormatter that would do
> the trick. I may have forgot to add it, I have it on my machine ( I hate too
> the default format ).
> There's also a config override allowing default properties to be loaded from
> a different location.
>
> Costin
>
> On 8/2/07, Remy Maucherat <re...@apache.org> wrote:
>> Rainer Jung wrote:
>>>>> That's why it would be nice if someone took the burden of writing a
>>>>> better log formatter for j.u.l.
>>>> Got it. Yea, that format is certainly grep unfriendly.
>>>>
>>>> Looks like Harmony has a formatter we could copy from and fix to not
>>>> add the new line.
>>>>
>>>>
>> http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java
>>> Yes, that could be a good starting point (although that implementation
>>> does not care about localization).
>> It might be better to use log4j code as a starting point as it already
>> has the pattern processing code.
>>
>> Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Juli/Logging
Posted by Costin Manolache <co...@gmail.com>.
I think something is missing - DirectJDKLog is looking for a
JdkLoggerFormatter that would do
the trick. I may have forgot to add it, I have it on my machine ( I hate too
the default format ).
There's also a config override allowing default properties to be loaded from
a different location.
Costin
On 8/2/07, Remy Maucherat <re...@apache.org> wrote:
>
> Rainer Jung wrote:
> >>> That's why it would be nice if someone took the burden of writing a
> >>> better log formatter for j.u.l.
> >>
> >> Got it. Yea, that format is certainly grep unfriendly.
> >>
> >> Looks like Harmony has a formatter we could copy from and fix to not
> >> add the new line.
> >>
> >>
> http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java
> >
> > Yes, that could be a good starting point (although that implementation
> > does not care about localization).
>
> It might be better to use log4j code as a starting point as it already
> has the pattern processing code.
>
> Rémy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Juli/Logging
Posted by Remy Maucherat <re...@apache.org>.
Rainer Jung wrote:
>>> That's why it would be nice if someone took the burden of writing a
>>> better log formatter for j.u.l.
>>
>> Got it. Yea, that format is certainly grep unfriendly.
>>
>> Looks like Harmony has a formatter we could copy from and fix to not
>> add the new line.
>>
>> http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java
>
> Yes, that could be a good starting point (although that implementation
> does not care about localization).
It might be better to use log4j code as a starting point as it already
has the pattern processing code.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Juli/Logging
Posted by Rainer Jung <ra...@kippdata.de>.
>> That's why it would be nice if someone took the burden of writing a
>> better log formatter for j.u.l.
>
> Got it. Yea, that format is certainly grep unfriendly.
>
> Looks like Harmony has a formatter we could copy from and fix to not add
> the new line.
>
> http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/modules/logging/src/main/java/java/util/logging/SimpleFormatter.java
Yes, that could be a good starting point (although that implementation
does not care about localization).
Thanks for the pointer!
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Juli/Logging
Posted by David Blevins <da...@visi.com>.
On Aug 1, 2007, at 1:30 AM, Rainer Jung wrote:
> David Blevins wrote:
>>> My personal opinion: java.util.logging very much lacks a good
>>> formatter. The default 2 line formatting of messages, splitting
>>> timestamps and message in separate lines, is not really useful in
>>> production. Many ad hoc log analysis practices work on a line
>>> oriented basis.
>> Was wondering about that. I've heard people grumble about
>> java.util.logging, but haven't (till now) heard anything
>> specific. Maybe I wasn't paying close enough attention, but the
>> Tomcat 6 log files still seem to follow the one line per message
>> format. How did you pull that off?
>
> That's what I get:
>
> Aug 1, 2007 10:26:37 AM org.apache.coyote.http11.Http11Protocol init
> INFO: Initializing Coyote HTTP/1.1 on http-28680
> Aug 1, 2007 10:26:37 AM org.apache.catalina.startup.Catalina load
> INFO: Initialization processed in 2854 ms
> Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardService start
> INFO: Starting service Catalina
> Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardEngine start
> INFO: Starting Servlet Engine: Apache Tomcat/6.0.13
> Aug 1, 2007 10:26:40 AM org.apache.coyote.http11.Http11Protocol start
> INFO: Starting Coyote HTTP/1.1 on http-28680
>
> One line for timestamp, class and method, a second line for log
> level and message. That's the format of the default formatter, the
> simple log format.
>
> That's why it would be nice if someone took the burden of writing a
> better log formatter for j.u.l.
Got it. Yea, that format is certainly grep unfriendly.
Looks like Harmony has a formatter we could copy from and fix to not
add the new line.
http://svn.apache.org/repos/asf/harmony/enhanced/classlib/trunk/
modules/logging/src/main/java/java/util/logging/SimpleFormatter.java
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Juli/Logging
Posted by Rainer Jung <ra...@kippdata.de>.
David Blevins wrote:
>> My personal opinion: java.util.logging very much lacks a good
>> formatter. The default 2 line formatting of messages, splitting
>> timestamps and message in separate lines, is not really useful in
>> production. Many ad hoc log analysis practices work on a line oriented
>> basis.
>
> Was wondering about that. I've heard people grumble about
> java.util.logging, but haven't (till now) heard anything specific.
> Maybe I wasn't paying close enough attention, but the Tomcat 6 log files
> still seem to follow the one line per message format. How did you pull
> that off?
That's what I get:
Aug 1, 2007 10:26:37 AM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-28680
Aug 1, 2007 10:26:37 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2854 ms
Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Aug 1, 2007 10:26:37 AM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.13
Aug 1, 2007 10:26:40 AM org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-28680
One line for timestamp, class and method, a second line for log level
and message. That's the format of the default formatter, the simple log
format.
That's why it would be nice if someone took the burden of writing a
better log formatter for j.u.l.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org