Hi! Whenever I read "trace", my first thought is s.t. like: 10:00 entering Berlin(byCar) 10:20 entering Berlin-Tempelhof(perPedes) 10:30 leaving Berlin-Tempelhof(perPedes) -> returned Sister 10:55 leaving Berlin(byCar) -> returned Sister
Most of this info can be acquired by logging a "new Throwable()" wherever you need a stacktrace (though you lose info about the history, e.g. which other method calls have returned before...). The use cases presented for the TRACE level so far suggest another name for it since they would use it for the verboser part of DEBUG. The level hierarchy needed for those use cases looks like: ERROR-WARN-INFO-DEBUG(terse)-DEBUG(verbose/with all data displayed) I cannot think of a naming for the two debug levels which makes their purpose obvious and prevents "abuse". Perhaps that's why Sun used FINE, FINER, FINEST; just because there are no "good" names to suggest what they really are? The terse debug to locate the source of a problem, in terms of classes and methods (preferrably one liners) and the verbose debug displaying the data being processed. As niclas already stated: >And I could go with a trace() as well to make people happy, although I > think the name is very bad. notice() or verbose() is IMHO a lot > better, sitting between INFO and DEBUG. BUT this conflicts with the use of log.trace() since trace is the least serious level in JCL. The other dimensions (logger hierarchy and Markers) are as well useful at least for framework- and tools-developers (anyone who delivers components to developers). The logger, sometimes referred to as category-, hierarchy I find indispensible to focus on certain components when debugging (and to block out unwanted verbosity). I prefer using classnames here, since packages and classes usualy already have a useful hierarchy; no need to invent another one IMHO. This way I can switch DEBUG on/off for whole packages or just single classes (and do not need to know, which logger this particular class might use, it's the class name). I do not expect Markers to be useful, or even visible, to end users of applications, which use slf4j, if they do not insist to use this feature. For developers of components and tools used to build and run that same application, they will probably help a lot, if they are easy to use and configure. As long as the ability to use a feature of the logging framework does neither impose any effort on the END USER of an application, nor affects its performance considarably, I think it's ok to have it. Just my 0,02 €, Heiner _______________________________________________ dev mailing list [email protected] http://slf4j.org/mailman/listinfo/dev
