My guess is that it's a lot more portable to use a long value of the
java.util.Date.getTime(). Timestamp relies on the DB having the same exact
clock as the app, and don't even get me started talking about TimeZones
I'm +1 on just storing that long value.
Paul
-Original Message-
In DBAppender why is logging_event.timestamp a number instead of timestamp?
James Stauffer
Hi,
>b.t.w. The license link on http://logging.apache.org still refers to
the
>1.1 license whereas the link at
>http://logging.apache.org/site/binindex.cgi when I try to download
log4j
>refers to 2.0 license.
El fixo has been completo. (Apologies to any Spanish speakers on the
list)
Yoav
T
Hi Scott,
I just tested it & it works fine. Thank you for the quick response!
- Phil
-Original Message-
From: Scott Deboy [mailto:[EMAIL PROTECTED]
Sent: Friday, May 14, 2004 3:23 AM
To: Log4J Users List
Subject: RE: log4j 1.2.8 and Chainsaw v2
Philip,
I've updated the LoggingEven
> > IANAL (that's really becoming a common acronym, it's too bad we all have
> > to deal with this ;)), the Apache License may apply to all Apache
> > intellectual property. That includes software, but also documentation
> > and other stuff (e.g. mailing lists, for example ;)). So you can
> > sli
> IANAL (that's really becoming a common acronym, it's too bad we all have
> to deal with this ;)), the Apache License may apply to all Apache
> intellectual property. That includes software, but also documentation
> and other stuff (e.g. mailing lists, for example ;)). So you can
> slightly modi
Philip,
I've updated the LoggingEvent serialization code, which should resolve this issue.
Download the latest version of log4j from CVS and you should be able to use Chainsaw
V2 to view log4j 1.2.8 socketappender-generated events.
Thanks,
Scott
-Original Message-
From: Lawrence, Ph
