At 05:45 PM 10/30/2003 +0100, Endre Stĝlsvik wrote:
- I'd still want trace!!! -
How would the domains help me with my initial concern: needing extremely
verbose information about the thing I'm currently working with (whether
it's new code or fixing/debugging or extending old code), while having
"heavy" debug information for the rest of the system, to get relevant
context for the trace-parts. Argh, this seems so blatantly obvious to me!!
Domains would help because many TRACE statements are TRACE statements
because they pertain to a certain category*** even if there are
explicitly recognized at such. For example, many people have a log
statements at the beginning and at the end of some methods. These log
statements, when enabled, usually generate large amount of output. So
we could label them at the TRACE level. That is one way to do it.
*** (category in the sense of division in a system of classification,
a class)
We could also treat the problem differently using domains. Assume all
log statements at the beginning and end of methods calls behaved as
usual depending on their logger name, but in addition they belonged to
the "method" domain which could be enabled disabled independently of
loggers. Thus, we could replace TRACE level by the "method" domain. We
could go one step further and have all the log statements at method
entry pertain to the "method.entry" domain and at method exit to the
"method.exit" domain. In that case, we could disable log statements at
the beginning or end of methods independently. That is why I say that
domains allow for very fine grained logging which additional levels,
such as TRACE, are incapable of.
|
| That's what domains bring you and that is why I think TRACE will be
| redundant in 1.3.
No, it won't! What about all the other levels? Remove them too, then? Why
would trace be left redundant, but not the other levels?
That is actually a very good question. The existing levels serve as an
*implicit* separation into 5 domains (FATAL, ERROR, WARN, INFO, DEBUG)
with an ordering relation between the 5. By insisting on ERROR, INFO,
DEBUG etc. we are perhaps perpetuating an outdated way of tackling the
logging problem.
Endre.
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
import org.apache.Facetime;
ApacheCon US 2003, 18-21 November http://apachecon.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
