Record sharing and mapping diagnostic contexts
As far as I know, the fact that the Commons Logging project (for .NET and Java) doesn’t support mapping or nesting diagnostic contexts, what has anyone else done?
Best Solution
Executive Summary:
We chose to use the implementer logging framework directly (log4j in our case).
Long answer:
Do you need an abstract logging framework to meet your requirements? They’re great for libraries that want to work well in whatever host environment they end up in, but if you’re writing an application, in many cases you can just use the implementation logging framework (i.e. there’s usually no reason why logging implementers should change over the lifetime of the application).
We chose to use the implementer logging framework directly (log4j in our case). Commons-Logging is available in the classpath, but it exists only for the libraries that depend on it. In our case, this is an easy choice because the company I work for has made log4j mandatory for years and is unlikely to change, but even if this is less obvious, it comes down to some cost/yield analysis.
- What benefits do NDC and other professional features bring me?
- How likely is it that the logging implementer will have to be changed? If it has to be changed, how much will it cost?
Maybe:
- Do I have to support different logging implementers in simultaneous deployments?
In our case, we’ll need to refactor a bit if we need to change the logging implementer, but for everything in the org.apache.log4j package, this is neither a difficult nor a very risky refactoring 1 。 The log4e Eclipes plug-in happily automatically converts the actual log statements; NDC objects can be a problem because not all logging frameworks support such a thing. You can consider hiding the NDC.enter() and NDC.leave() methods in utility classes that you control yourself, we didn’t bother.
1) Famous last words