| I haven't discussed this personally with Ceki, but I until I hear
| differently, I think the simple answer is "yes", levels *will* be supported
| in the next version of Log4j, possibly deprecated, though. The idea being
| eventual migration to logging domains, especially with newer codebases that
| don't yet have any dependency on levels. Consequently, the avoidance of
| adding new levels will probably encourage migration to logging domains.
There is an existing LARGE userbase that uses levels, which -won't- switch
to domains on their existing projects. Maybe new projects will use
domains, but not the existing projects. But maybe (as for our system) the
existing projects are -that- large that they won't "ever" be finished.
They will, though, forever still be maintained, and evolved and have lots
of new code added, and lots of old code refactored etc. THIS use case
would still like to have trace - even though domains -possibly- would be
better (although I feel that it's a COMPLETLY different idea - but good).
"Encourage migration". Well, isn't that a bit "haevy-handed"? I haven't
ever asked for domains. I don't think, based on what I've heard so far,
that I'd be satisfied with domains (As I've already stated, I use the
categories in a more "reflected" manner than simply the classname, hence I
already have a notion of the "domain" of the log lines). Thus, this is a
forced migration into something that I haven't asked for, and the existing
functionalty won't get updated or developed to what I (and others, right?)
am asking for.
Based on what I've understood of domains so far, I also put a question
mark at the performance of domains, vs.:
if (log.isTraceEnabled()) log.trace("User [id:"+user.getId()+"] added to update
queue.");
This is probably the absolutely fastest thing that can be done (I believe)
- a simple boolean no-args method, that (hopefully!) is made to be a
simple boolean check and return if disabled. Making your own trace level,
means that the if would have to pass an argument to the
isLevelEnabled(level), and that method again would have to do a further
lookup. The domains-thing so far seems like a "string-based" lookup, which
to me sounds even worse.
The deal here is that since the trace-level should return the absolutely
most amount of imformation (an argument for this below!), this exact
method should have the absolutely least amount of overhead to the "is it
on" check - this, of course, to be able to leave those statements behind
when you're finished with the code - being ensured that it doesn't make a
(significatnt) overhead to the all around opearation of the code.
Then again, I might be totally mistaken ..
Or maybe we all should migrate to preprocess our code?!
And now for something a little different:
A little argument for "Trace" being lower (more verbose) than debug:
"tracing" an application is usually referring to "step-locking"
through code, that is, seeing every single change to every single register
in the processor, for every operation. For unixers, "strace" and "ltrace"
are the tools by which -all- system calls / library calls are "traced".
The "trace" word hence, in my opinion, have an established meaning as
something -extremely- verbose: it -traces- the applications every single
step.
Debug information, on the other hand, is more for being able to debug
the application as a whole (and this is, of course, a very overlapping
area!). You'd like to see when the application asks the dbpool for an
connection (maybe? - the 40 steps required within the dbpool to fetch this
connection are at least definately trace-level outputs), you'd like to see
that the user made some "semantic action", e.g. "loaded customer data".
This is more "contextual" information, e.g. "the user such and so mande
the this and that action", and, implicitly, if you'd turn on trace, you'd
see -which- small, single-steps that have been done to accomplish this
action.
I don't know if this was extremely elucidating, but hey..!
Here's some dictionary lookups:
Onlook.com:
http://onelook.com/?w=trace&ls=a
Dictionary.com:
http://dictionary.reference.com/search?q=trace
Tiscali's computer dictionary:
http://www.tiscali.co.uk/reference/dictionaries/computers/data/m0034421.html
CSGNetwork.Com:
http://www.csgnetwork.com/glossaryt.html#trace
Some quotes:
"A method of checking that a computer program is functioning correctly by
causing the changing values of all the variables involved to be displayed
while the program is running."
"To follow the course or trail of: trace a wounded deer; tracing missing
persons."
"To determine the "flow" of a program, often used as a synonym to debug".
"To locate or discover by searching or researching evidence: trace the
cause of a disease."
"A mark left by anything passing; a track; a path; a course; a footprint;
a vestige; as, the trace of a carriage or sled; the trace of a deer; a
sinuous trace."
"A mark, impression, or visible appearance of anything left when the thing
itself no longer exists; remains; token; vestige"
"To follow by some mark that has been left by a person or thing which has
preceded; to follow by footsteps, tracks, or tokens."
"a clue that something has been present; "there wasn't a trace of evidence
for the claim" "
"A line drawn by a recording instrument, such as a cardiograph."
Seems to me like "log4j" maybe should have it's name changed to the more
descriptive "trace4j", or what?! ;)
--
Mvh,
Endre Stølsvik M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS - http://www.coretrek.com/
CoreTrek corporate portal / EIP - http://www.corelets.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
