RE: discreet logging types - revisited

["Shapira, Yoav" <Yo...@mpi.com>]

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:lyoung@dalmatian.com]
>Sent: Thursday, August 14, 2003 3:10 PM
>To: log4j-user@jakarta.apache.org
>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: log4j-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-user-help@jakarta.apache.org




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: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org

RE: discreet logging types - revisited

[Ceki Gülcü <ce...@qos.ch>]

At 12:37 PM 8/14/2003 -0700, Larry Young wrote:
>Yoav,
>
>         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!

Yes, I totally agree. The current design of log4j caters for categorizing 
messages by locality, that is the place where the logging request is issued 
(package, class). Although most of the time categorizing logs by locality 
serves us well, very well, we sometimes need to categorize the logging 
request by some other criteria.

I think your observation is quite insightful.


>--- regards ---
>Larry

-- 
Ceki For log4j documentation consider "The complete log4j manual"
      ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp




---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org