I believe there is a plan in place to do this with some kind of "logging context" in a future release. I'm not part of the dev list, so I don't know that for a fact, but it is my understanding from various responses to some problems that I had early on with these issues.
My biggest issue is that I don't agree with the forced relationship between Levels, especially when you add additional Levels to the standard package. Why is "trace" higher or lower than "debug" or "info"? I don't agree that this is a fixed relationship, it depends on the circumstances. Then you add additional Levels (DB Access, Timing, etc) and it gets even muddier. I think you are right, there is a dual notion of what a Level is. It is used for both turning on/off logging (with an implied relationship between the various Levels) and also to define the type of info being logged.
For my purposes, I've created something like what you describe by wrapping the Logger class to remove the entire concept of Levels and replaced it with a LogType concept. Now, I can turn on/off logging for any particular LogType totally independent of any other LogType, because there is no inherent relationship between them. The nice part is that if I choose to have a relationship between them I can, but the Logging class doesn't make that assumption, that's up to the LogType to decide if it is "enabled". So in my config file I select what Type of info I want logged, not the Level (and its related Levels).
Unfortunately, I didn't have the time to rewrite the Logger class to replace Levels (Levels and their implied relationships are embedded pretty deep in log4j), so I used a "poor-man's" context by prefixing each logger's "class name" with a "log type" name, which gives me roughly the same outcome (i.e. turning logging on/off by type instead of by group which is how levels work), albeit a bit ugly in the config file. Happily, the Java code is unaware because the wrapper does all the translation work.
Probably the biggest problem I can see with this approach is that it's not exactly compatible with Java 1.4 Logging, which in my case doesn't bother me because I don't think logging belongs in the language anyhow! :)
--- regards --- Larry
At 04:52 PM 9/23/03, you wrote:
It seems obvious enough why there is wide disagreement on how to use the existing levels and/or whether more levels are needed. People are trying to cram selectively enabled logging into log4j's strict hierarchical logging scheme.
What I think mos people want is some reasonable way of saying how much logging they want (and the current scheme is fine for that) along with saying what kind of information they want logged (the current scheme is lousy for that). What folks probably want for the latter is the ability to turn on and off some selection of "items of interest".
I'm sure many people independently do this outside of log4j. I don't know if it would be easy / reasonable / worthwhile to have some facility inside log4j that implemented the same idea. You might be able to cook up some "items of interest" that were interesting to many development efforts, but there would certainly be unique elements that folks would want to use to supplement that. -- [EMAIL PROTECTED] (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
--------------------------------------------------------------------- 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]
