On Wed, 18 May 2005, Scott Deboy wrote: | I personally see TRACE as unrelated to severity, so if I were to have | unlimited resources, I'd prefer to implement per-event attributes | instead.
"Trace" and "debug" are not -severity-. "Fatal", "Warn", "Error" and "Info" are. Trace and debug are both "developer"-levels. All the others are "production levels". And by now, there is only one developer-level. Which I find totally weird. Trace and debug are only about -amount- of developer-information, not -severity-. Things logged on trace aren't "more severe" than debug as such, but maybe kinda "a more major event" that would give nice context-information to other prod-levels/debug/trace lines. | | However, I'm not against the change because I understand there are a | group of people who want more data points and this is the easiest way to | get it. It definately is. | | If we decide at some point in the future to support attributes at the | event level (MDC and NDC don't fit the bill here), I can enable an | aspect-oriented style of logging by adding attributes describing the | aspects on the event: 'database', 'authentication', etc. Isn't this pretty much what "domains" will do?! Why wouldn't the MDC fit the bill? (These are honest curiousity-questions, not a part of the discussion!) | | When I want to 'trace' the 'authentication' process, I enable logging | for events with the 'authentication' attribute. What if you want to -trace- some prameter-sending stuff, but just want the debug-output of the authentication, just to see -where- the parameters are handled in regard with the auth?? (Get context) .. or something similar? The whole point is that trace/debug -level- is completely orthogonal to domains or categories or whatever. It is another axis. You _could_ make a domain / category with "authentication.trace", as Ceki have suggested. But then you could do the same with -all- levels. Would it make sense with "authentication.[fatal|error|warn|info|debug]" domains/categories too, then? This immediately, in my opinion, implies that the concepts we're discussion are orthogonal. The problem is that one probably shouldn't have started with the special-methods for levels in the first place: They should all have been a part of the arguments-set to the method-call, a programmatic/definable element on the same level as category-names are. But now that they're here, it doesn't make sense to exclude the CLEAR desire to have the -topmost- level, the one which will get definately the most log-lines and code. I'll state it again, just to get this little point across: I don't like the category-naming based on class-names: one have methods to get the class-name (and line) of a log-line already - thus category would then become redundant information in my view. I personally use categories as "functional groups": "authentication", "database" etc.. As I've understood domains, these will remedy my problem where I sometimes end up wanting to output some log-statement to two different parts of my category-tree. But that is just what I do if that need becomes to intense: make two loggers, one for each functional part (different categories, ja?), and output the same log-line to both of them. This has nothing to do with levels. Regards, Endre --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
