logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Young <lyo...@dalmatian.com>
Subject Re: discreet log types
Date Sat, 02 Aug 2003 00:47:21 GMT

         Thanks for the response.  Let me repeat back to you what I think 
you are saying to be sure I understand.

         Basically you are using MDC (I don't think NDC would be quite 
right, and not sure what Properties are in this context) to add a 
"user-specified" attribute to each logging call.  Since MDC preserves these 
per-thread, they would only apply to the caller's data.  I'm assuming that 
the MDC data is available in the LoggingEvent object (I know NDC is).  So 
assuming that the "log type" is the data put into the MDC, then the Filter 
can check that against the current setting for that type, but it will still 
have to scan the package hierarchy programmatically to see if that type is 
enabled for the calling class.  This might be a problem with nested timing 
blocks if I try to use MDC for the timing info also, I need to give that 
some more thought.  Perhaps that is where NDC would come in handy.

         If that's not what you were suggesting, please correct as 
necessary.  Otherwise, I'll give that a try!

--- regards ---

At 09:31 AM 7/31/03 +1000, you wrote:
>Hi Larry,
>This is where you would probably delve into the MDC/NDC/Properties
>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.
>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
> >
> >

Larry Young
The Dalmatian Group

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

View raw message