On Wed, Jul 13, 2005 at 05:29:13PM +0200, nick vajberg wrote:
> A few opinions:
> In general, I'd like the logging facility to be
> independent of server. That is, logging should work
> the same way whether running httpd or svnserve or
> something else.
> That way, if the logging API got pluggable, even svn
> under httpd could benefit from stuff like networked
> logging (rather than polluting the apache log)
Ideally, the code could be instrumented with logging/trace
calls that behaved appropriately (though perhaps differently)
under both svnserve and httpd. That may be exactly what you're
> >> 4.1 Customizable Log Format
> Make it fixed so people can easily write tools that
> parses and aggregates/presents the log info in various
> ways. The alternative is to write API's for traversing
> the log, but that's not worth it IMO.
> >>4.3 Support for syslogd
> Note that there are syslogd ports for win32. At any
> rate, please don't even consider using the NT event
> log; files rule in this case.
> >> 4.2 Support more verbose output and debug tracing.
> I disagree with brane that logging and debug logging
> are different animals - that's just a load of crap.
> More than once have I turned on the debug level in
> stuff like Hibernate without even restarting the
> server running it.
My guess is that your complex Java application actually
has two logging facilities:
1.) Application-level audit-logging of things like "user
logged in", "user logged out", "user changed password", and
perhaps even "user ran report Foo with criteria Bar".
This probably gets logged in a database table (or tables)
in a structured or semi-structured way, and has all kinds
of application-level tools built around it.
If your application doesn't have this, it probably isn't
2.) log4j, for troubleshooting, monitoring, debugging,
> The log4j levels are good examples and it works really
> well in practice.
log4j is great at (2), it's not-so-great at (1), especially
in environments where the audit trail is extremely important
(think SOX compliance).
> >> 4.5 XML Logging format
> Don't go there. Please.
I agree that for (2) it's usually a bad idea. For (1), it
is occasionally the least-evil solution.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Jul 13 22:47:00 2005