Logging Commons and Mapped Diagnostic Context

Question

What have others done to get around the fact that the Commons Logging project (for both .NET and Java) do not support Mapped or Nested Diagnostic Contexts as far as I know?

Answer 1

Exec summary:

We opted to use the implementor logging framework directly (in our case, log4j).

Long answer:

Do you need an abstract logging framework to meet your requirements? They're great for libraries that want to play nice with whatever host environment they end up in, but if you're writing an application, you can just use the implementing logging framework directly in many cases (i.e. there often isn't any reason why the logging implementor should change over the course of the application's life).

We opted to use the implementor logging framework directly (in our case, log4j). Commons-Logging is available on the classpath, but it's only there for the sake of the libraries that depend on it. In our case it was an easy choice, as the company I'm working for has had log4j as a mandatory standard for years and it's unlikely to change, but even if that's less obvious, it boils down to a bit of cost/benefit analysis.

• what's the benefit NDC and other specialty features give me?
• what's the chance of having to change logging implementor, and what's the cost if I have to?

and maybe:

• do I have to support different logging implementors in simultaneous deployments?

In our case, if we ever are required to change logging implementors, we'll have some refactoring to do, but with everything in the org.apache.log4j package, that's neither a difficult nor a very risky refactoring¹. The log4e Eclipes plugin will happily convert the actual logging statements automatically; the NDC object could be a problem because not all logging frameworks support such a thing. You could consider hiding the NDC.enter() and NDC.leave() methods inside a utility class under your own control, we didn't bother.

---

¹) famous Last Words