Yes, these are both ideas that I've been looking at. If I change Logger (either wrap or create a new one), then I will probably use a separate repository to avoid the problems that Ceki discusses in his book.
As for Filters, the problem there is that Filters are attached to Appenders, not to Loggers. In my first post two weeks ago, Paul responded with the same suggestion, but since the permitted types will vary by each logger, I would have to either build a parallel hierarchy to hold the types for each logger, or define appenders for each logger that I wanted to change the permitted types (and that could get rather ugly). I understand how to use MDC to tag the LogEvent with the type, but then I need to see if that logger should allow that type, that needs to be stored either with the logger, or in yet another "global" collection keyed by logger.
And again, I'm not trying to say that levels are bad, it just that they are only one way of determining what should get logged. Thanks for the suggestions!
--- regards --- Larry
At 03:07 PM 8/14/03 -0400, you wrote:
Howdy, I'm a fan of the Level system and its relationship, so no I'm not interested in your suggested mods, but I wanted to throw out an idea or two for you that might reduce the need for coding: - Can you use separate logger repositories as your "types" ? - Can you use a Filter attached to the root logger that matches based on "type" as an MDC attribute of the logging event?
Yoav Shapira Millennium ChemInformatics
>-----Original Message----- >From: Larry Young [mailto:[EMAIL PROTECTED] >Sent: Thursday, August 14, 2003 3:10 PM >To: [EMAIL PROTECTED] >Subject: discreet logging types - revisited > >Hi all, > > Well, I'm still looking at how to use discreet logging types >instead of the Level to control what messages are "enabled". The >difficulty resides in the need to enable/disable certain log types by >package/class name. BTW, I posted my original message on 7/30/03 if you >are interested. > > Basically, the way I've always built logging systems is by >defining a set of discreet types to be used by the developers, and then >allowed those types to be enabled/disabled individually. Unfortunately the >"level" concept is fairly hard-wired into log4j. I say "unfortunately" not >because levels are bad, but because there is no way to expand or get-around >them with an alternate approach. Actually, levels can be viewed as a set >of discreet types with an implicit ordering/relationship between them, but >in log4j, there is no way to control the relationship test. > > Before I go on too much (which I do!), is there anyone else who is >interested in discussing the idea of replacing the "level" with "discreet >types" in the log4j package?? Basically I'm at a point where I need to >make some decisions regarding how to proceed. If other members are >interested in pursuing this idea, then I'll explore the idea of modifying >the Logger classes (et. al.) to replace the level with types, with the >intention of folding those changes back into the product. But if no one is >interested, I'll just make some small mods to Logger for my own purposes >and handle it as a "one-off" type situation. In either case, I intend to >move forward with log4j! It has many features which I'm planning to use in >the future (like that IMAppender being discussed!!). Mostly its a matter >of whether I do a complete implementation to replace levels, or just a >quick fix to solve my problems. > > Thoughts, comments ??? Ceki, as one of the main champions for >log4j, do you have any input? > >--- regards --- >Larry > > >-------------------------- >Larry Young >The Dalmatian Group >www.dalmatian.com > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------
Larry Young
The Dalmatian Group
www.dalmatian.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
