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]

Reply via email to