What you said is true. But we're talking about something slightly different. Let's say you want to filter the jakarta-commons httpclient package out of your logging, EXCEPT when you're calling that package from the section of your code that you're currently debugging. That's not something you can easily do, because you don't know the calling context without either examining the stack to see who called you (and how far up the stack do you look, anyway?) or manually calling some code that turns on and off the extra logging for the current thread.
--Ian --- Scott Heaberlin <[EMAIL PROTECTED]> wrote: > Perhaps I am wrong, but I thought the hierarchical nature of Loggers > allowed you to do this? For example, when I use the jakarta-commons > httpclient package, it always logs wayyy more than I want to know... > simply adding a <logger> element in my log4j.xml whose name is the > httpclient package and whose level is WARN sufficiently squelches > httpclient code save for warnings and errors. > > For example... > > > package com.mycompany.firstmodule > classes A, B, C, D. C & D have lots of log.debug statements that I > want > to squelch. <logger name="com.mycompany.firstmodule" > additivity="false"> with a level of "WARN" would sufficiently squelch > both C & D but also A & B. If I didn't want to squelch A & B, I'd > have > to define named loggers in my log4j configuration for both C & D - > specifically what the original poster didn't want to do. > > Assuming you do like I do and declare your logger instances as: > private static final Logger log = > Logger.getLogger(<ThisClass>.class); > then the above solution should work, I believe. > > Please corect me if I am wrong. > > > -Scott Heaberlin > > > > > -----Original Message----- > > From: Paul Smith [mailto:[EMAIL PROTECTED] > > Sent: Friday, February 06, 2004 4:42 PM > > To: Log4J Users List > > Subject: Re: logging in util code > > > > > > The only way I could think of doing this is in the client > > code that is going to call the component, place something in > > the NDC or MDC to identify it, and then you can filter it at > > the appender level for the component logger. > > > > Of course if you do not have control over the client code, > > then this is not possible. > > > > Heres were Aspect programming would be useful, I think. > > > > cheers, > > > > Paul Smith > > On Sat, 2004-02-07 at 06:38, [EMAIL PROTECTED] wrote: > > > I'd love to be able to do this, also. But log4j doesn't provide > a > > > ready-made way to do this. You could write a filter that would > > > examine the call-stack of the LogEvent passed to it, but of > course > > > that's quite a performance hit. > > > > > > --Ian > > > > > > --- Nathan Coast <[EMAIL PROTECTED]> wrote: > > > > Hi > > > > > > > > I have debug statements in core utilities, the problem is > > that when > > > > I turn debug on for these components, the volume of debug is > too > > > > great. Is there any way to > > > > turn on debug for a component based upon the calling > > system (package) > > > > as oposed > > > > to the classname of the util component? > > > > > > > > Thanks > > > > Nathan > > > > > > > > > > > -------------------------------------------------------------------- > > > > - > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
