((I already voted, so just a comment here.))
Though I voted in favor of TRACE, it's not because I need *more*
levels of logging. In fact, I could probably get by with about 3.
So why don't I just ignore the particular words used to identify the
levels and use 3 or so of them for whatever purposes I desire?
The problem is that I don't deploy my application in isolation. I
must often fit my product into other frameworks (Tomcat, J2EE
application servers, custom frameworks of various unpredictable
stripes). Some of those environments use log4j already as the
standard logging stuff, and in some cases other add-ins like mine
might choose to use log4j.
I believe the administrators of those environments also can do with
just a couple of logging levels because there are only a handful of
scenarios that they want to instrument (e.g., full production mode
with only essential logging, whole hog debug mode where everything
dumps out and performance tanks, and maybe one or two things in
between).
Now, it is a non-trivial inconvenience to those administrators if
DEBUG means different things for different parts of the environment
they're running, so I try to wedge all my stuff into the connotations
of the names of the existing levels. That leaves me to collapse what
I think of as trace information ("everything that happens" ... I don't
use trace to means just method entry and exit) into DEBUG ("things
that would be interesting to a developer" ... even though this can
sometimes be dumped out from production environments).
OK, the real point of my comment is that the argument of "you can use
the existing levels for whatever you want regardless of their names"
isn't always reasonable.
--
[EMAIL PROTECTED] (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
