[prev in list] [next in list] [prev in thread] [next in thread] 

List:       log4j-user
Subject:    Re: discreet log types
From:       Paul Smith <paul.smith () lawlex ! com ! au>
Date:       2003-07-30 23:31:24
[Download RAW message or body]

Hi Larry, 

This is where you would probably delve into the MDC/NDC/Properties
usage.

At each 'type' point/location in code I would add a MDC/NDC/Property
(whatever works best) at the point, and remove it afterwards where
appropriate.  The log events generated between these places would then
have a Level, belong to a Logger (you're class/interface/logger name),
and have additional information for your 'type'.

Then it is just a matter of configuring Filters at the appender level to
filter out events that you're not interested in for that appender.  You
might have to develop some custom Filter classes to meet your needs, or
re-use/build on the Filter classes that are in Log4j, but that's the
approach I would use.

Configuration reloading is free out of the box, just register a File
Watchdog (see the PropertyConfigurator.configureAndWatch(file,
watchTime) method, plus the DOMConfigurator obviously has this too).

I hope this helps you.

cheers,

Paul Smith

On Thu, 2003-07-31 at 09:25, Larry Young wrote:
> Hello,
> 
>          I'm looking at creating a logging package for our applications 
> (web & non-web).   The reason for yet-another-logger is that I want 
> discreet logging types, not hierarchical levels.  I've built this kind of a 
> package before for previous projects, and ended up building the whole thing 
> because I didn't think log4j could do what I wanted (that was several years 
> ago).  Now I'm building another one, and looking at the current version of 
> log4j, and having read much of Ceki's book (which I highly recommend!), I'm 
> thinking that there's got to be a way of re-configuring (bending?) log4j to 
> do what I need.  I don't think it's that far off.
> 
>          Basically, I want to be able to enable/disable logging for a 
> particular class or package by type, and each type is totally independent 
> of every other type.  Some examples of types might be:  Fatal, Error, 
> Timing, CodeBlock, ControlPoint, DBAccess, Info, etc.  There is no implicit 
> "ordering" between these various types, so "levels" are inappropriate. What 
> I want to be able to do is to turn on/off each type independently, so that 
> I can turn on Timing without having to also turn on Info, or be able to 
> turn on CodeBlock without turning on Error.  I also want the users of my 
> package to be able to define additional types and register them with the 
> logger at runtime (via code or xml ???).  Oh yeah, I also need to have the 
> logger reload the config file (or some portion of it) on a regular basis so 
> that we can change the enabled types without bouncing the app-server or 
> restarting the application.
> 
>          I was thinking if I tried to tie all my "types" to a single 
> "level", and did something with the log-level filtering to enable/disable 
> by package or class, that would get me close.  I'm not sure how I'd tie in 
> the "type".  I'd probably have to programatically update the log-level 
> filters with updates to handle config changes at runtime.
> 
>          Thoughts, ideas, concerns???    Any comments are gratefully 
> accepted!  :)
> 
> --- 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


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

[prev in list] [next in list] [prev in thread] [next in thread]