Originally I thought that malicious MDC inheritance caused problems only if you were careless, and forgot to either clear or retain the MDC information when switching threads. But there are situations when you don't have any kind of control over the ThreadPool, or the Runnables and Callables that get executed on it.
Think of a third-party library that uses a java.util.Timer or java.util.concurrent.ThreadPoolExecutor behind an API that exposes none of the threading logic, so you don't have a way to call MDC.setContextMap() anywhere. In this case you will end up with polluted MDCs everywhere.
I've created an issue for this:
Lorant
On Tue, May 31, 2011 at 10:52, Matthias Treydte
<waldheinz@gmail.com> wrote:
Hello,
> call chain. It was quite a nice surprise that MDC data automagically
> appeared in the log files because of the inheritance.
I absolutely agree it's a nice feature and helps to keep the code
clean, just as it did for you. But I also think that Lóránt's and my
objections are valid as well, if not simply because thread pools are
so common. So having the possibility to turn it on/off would be pretty
helpful. I think the "wrong data is worse than no data" argument is
pretty strong.
Kind regards,
-Matthias
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled. (R.P. Feynman)
_______________________________________________