OK, that's a useful compromise that makes log files easier to deal with.
Suggestion: If the timestamp appeared on the first line of the stack
trace (in addition to the preceding error message line), it would be
easier to search a log file for an exception, say
"OutOfMemoryException", and then loca
Stacks are always special. It's usually unfeasible to push them into one
line. My argument was about usual log messages. Of course in a fully
fledged new formatter, one would wish things like configuring the depth
of the stack printed.
Len Popp wrote:
On 7/31/07, Rainer Jung <[EMAIL PROTECTED
On 8/3/07, Costin Manolache <[EMAIL PROTECTED]> wrote:
> On 8/2/07, Len Popp <[EMAIL PROTECTED]> wrote:
> >
> > On 7/31/07, Rainer Jung <[EMAIL PROTECTED]> wrote:
> > > My personal opinion: java.util.logging very much lacks a good formatter.
> > > The default 2 line formatting of messages, splittin
On 8/2/07, Len Popp <[EMAIL PROTECTED]> wrote:
>
> On 7/31/07, Rainer Jung <[EMAIL PROTECTED]> 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 use
On 7/31/07, Rainer Jung <[EMAIL PROTECTED]> 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 w
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.PatternFormat
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 <[EMAIL PROTECTED]> wrote:
>
> Hi Costin (and Remy),
>
> I had a quick look at the JdkLoggerFormatter (
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 t
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 d
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
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/a
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/
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 a
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 se
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
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
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: [EMAIL PROTECTED]
For additional commands, e-mai
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.
W
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
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 t
20 matches
Mail list logo
