Hi, AFAIK, Log4J's MDC had no inheritance between threads -- this is a new feature introduced in Logback. However, when you are using thread pools, this new feature can cause a lot of trouble, especially when moving to Logback from a different logging system. Consider the following situation: you have a web application where you use the MDC to keep track of which user is logged in. You do certain things on the request processing thread. There are other certain things that you want to execute "in the background". You want to print the originating user's name in the logs for both "foreground" and "background" tasks. In such a case the Runnable's you place on the thread pool's queue need to take care of retaining the MDC from the originating thread. If you do this, and do this in every instance, no problem. However, it happens that you forget to do this. In such a case, with Log4J's non-inherited MDC, you would get no user name printed in the logs for background tasks, because your thread pool threads would not have anything in the MDC. That's not a good situation, but at least you can spot that there's something missing. OTOH, if you forget to retain the MDC manually with Logback, instead of no data you get false data in the logs. This is because thread pool threads are going to be created with random parent threads. These thread pool threads will then inherit the MDC from these threads, and *keep* the MDC. So future Runnables passed to these threads will print their starting thread's username. False data is worse than no data, so it would be nice to avoid this. Is there a way to make Logback's MDC inheritance configuratble? Like, in logback.xml you could set if you wanted to use InheritableThreadLocals or not. If that doesn't work, it might even be better to have no inheritance at all. What do you think? Regards, Lorant