> 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.
In my opinion, this scenario is what NDC/MDC was *made* for. Simply push a value onto the NDC stack or put it into the MDC table and you can filter out log events (from, say utility code such as our httpclient example) except those logged by subsystem X in our own application. Subsystem Y may also use httpclient, but since it does not initially store our value of choice in the NDC/MDC, it gets filtered out. While this relies on threadlocals (and subsystem X may have any number of threads), we'd have to remember to either copy and store these values when new threads are created or store it in some other manner. If, say our 3rd party code is what is creating these threads (and I do think that the NDC/MDC values are now correctly inherited into child threads, but I haven't verified that myself), I don't rightly have an answer other than perhaps extending whatever classes we need to better utilize log4j for our needs. ...And, if we're doing all this while debugging, we can easily filter by NDC/MDC using chainsaw (v2, of course! :) -Scott --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
