tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Chaffee <>
Subject Re: Tomcat Logging
Date Wed, 16 Aug 2000 12:03:29 GMT
On Tue, Aug 15, 2000 at 11:16:09AM -0700, wrote:
> What about spliting "logging" from "debugging" ? It's clear there are
> different requirements.

Yes, but not *that* different. 

Logging messages are often used for debugging, and it's not always
clear when a particular message is which.  

Here's a good quote I stole from the log4j docs:

As Brian W. Kernigan and Rob Pike put it in their book The Practice of

  As personal choice, we tend not to use debuggers beyond getting a
  stack trace or the value of a variable or two. One reason is that it
  is easy to get lost in details of complicated data structures and
  control flow; we find stepping through a program less productive
  than thinking harder and adding output statements and self-checking
  code at critical places. Clicking over statements takes longer than
  scanning the output of judiciously-placed displays. It takes less
  time to decide where to put print statements than to single-step to
  the critical section of code, even assuming we know where that
  is. More important, debugging statements stay with the program;
  debugging sessions are transient.

If there were two different services (log vs. debug), then (a)
developers would get confused as to which to use in the grey-zone
cases, and (b) we may diverge and thus not benefit from all the common
cases -> common code.

Here's my vision of What Tomcat Needs from a logging package:

(1) Configuration (via server.xml)
 (a) define files or non-file log targets by name
 (b) tell particular components, or sets of components, where to send their output, based
both on message type and/or message source
 (c) tell particular components how verbose to be (this covers Costin's need for per-component
debug level)

(2) Component API
 (a) standard interface for telling components all of 1a,1b,and 1c
 (b) very simple API for a component to send a message and/or stacktrace to appropriate log
(on the order of a mere 'log("foo");' just working)

(3) Logging Package
 (a) set of classes for sending messages to wherever they need to go
 (b) must be high-performance -- if disabled, then take minimal or no CPU/memory

Analysis of Existing Code:

log4j would take care of 3 but not 1 or 2

current tomcat.logging package takes care of 3, part of 2b

current server.xml takes care of some of 1, but in an inconsistent and
not-fully-baked manner

I'll send a proposal, including interface/class definitions, in a
separate message, but I'd like some feedback on the above analysis
before I proceed.

> Even debugging - there are 2 kinds of debugging - abnormal situations that
> happen at runtime and "traces" that you use to do println-debugging.
> I think it would be a good idea to use log(), debug() and trace() for
> example.

I agree that the utility of "WARN" is minimal, but I'd still like to
see different "categories" (log4j's term) for

* Error (important for users to always see these unless specifically

* Information (the default Log type; this is where servlet log()
messages would go)

* Debug (with the additional caveat that each component has a separate
variable determining which messages they shall send to this category)

"trace" is a grey-zone category; I think "debug" covers this need, so
"trace" is unnecessary and overcomplicates things.

> For trace() I think the clasic old prinln will be enough (
> since traceLevel should be 0 in normal use, enabled only to debug a
> component ).

Nope; what if the user is trying to debug an app that's hosted on an
ISP, that he can't view the console of?  ALL messages should be able
to be directed to a file or elsewhere, configurably.  Plus, this
actually makes things simpler :-)

 - Alex

Alex Chaffee             
jGuru - Java News and FAQs
Creator of Gamelan       
Founder of Purple Technology
Curator of Stinky Art Collective

View raw message