Getting a NullPointerException

[sjmuir]

I checked this in versions 1.3.14 and 1.5.10. In ch.qos.logback.classic.spi.LoggingEvent.getMDCPropertyMap(), I found this line:

MDCAdapter mdcAdapter = this.loggerContext.getMDCAdapter();

In some cases, I found that this returned null. This is not checked for, giving a NullPointerException on this line:

this.mdcPropertyMap = mdcAdapter.getCopyOfContextMap();

Please add a null pointer check.

[ceki]

@sjmuir The mdcAdapter to loggerContext is assigned when Logback is initialized by LogbackServiceProvider.

Are you using a loggerContext created in a unit test or are you initializing Logback on your own?

[sjmuir]

@ceki It's not a unit test, it's production code that we're trying to upgrade various libraries in, including logback.

This method is invoked by ch.qos.logback.classic.callAppenders(ILoggingEvent event). In my case, for this parameter:

event.toString() = "Logger[com.bluepumpkin.IU.FrameWork.FusionExchangeServer]"
event.parent.toString() = "Logger[com.bluepumpkin.IU.FrameWork]"
event.parent.parent.toString() = "Logger[com.bluepumpkin.IU]"
event.parent.parent.parent.toString() = "Logger[com.bluepumpkin]"
event.parent.parent.parent.parent.toString() = "Logger[com]"
event.parent.parent.parent.parent.parent.toString() = "Logger[ROOT]"
event.parent.parent.parent.parent.parent.parent = null

It's during the processing of "Logger[ROOT]" that the NullPointerException occurs.

[ceki]

@ceki Normally, the mdcAdapter of loggerContext is set at logback initialization time. The issue of unset mdcAdapter is known to happen in case some component of your application initializes logback independently. This is not a logback issue but an issue of some other component of your application. Are you perhaps using an old version of spring-boot?

[sjmuir]

We are not using spring-boot. We are using version 2.0.7 of org.slf4j:slf4j-api, org.slf4j:slf4j-jdk14 and org.slf4j:log4j-over-slf4j and version 1.3.14 of ch.qos.logback:logback-core and ch.qos.logback:logback-classic . I'm wondering if upgrading to 2.0.16 of slf4j* would fix the issue but I can't find release notes on slf4j to tell me what has changed in each 2.* release.

[ceki]

MDCAdapter mdcAdapter = this.loggerContext.getMDCAdapter()`

In some cases, I found that this returned null. This is not checked for, giving a NullPointerException on this line:

When you say that "in some cases" loggerContext.getMDCAdapter() returns null, do you mean that there are invocations which return a non-null value? I can imagine that the mdcAdapter is not assigned and hence returns null but the returned value should be null all the time and not intermittently.

What other components/frameworks are you using?

Release notes can be found at SLF4J's news page.

By the way, slf4j-jdk14 is an slf4j provider like logback-classic. It does not make sense to have more than one SLF4J provider.

[sjmuir]

getMDCAdapter() always returns null when I step through the code, but it must have worked in the past before we started upgrading things.

This a complex application, so I can't really comment on what other components/frameworks we're using.

Because our logging is based on log4j, according to the bottom left diagram on this page: https://www.slf4j.org/legacy.html
we should be using log4j-over-slf4j.jar, slf4j-api.jar and slf4j-jdk14.jar, along with logback-classic and logback-core. Therefore we are using "more than one slf4j provider" because that is what that diagram tells us to do.

[ceki]

If logback-classic is your logging provider of choice, you should be using jul-to-slf4j and not slf4j-jdk14, as shown in the top-left diagram.

Coming back to the bug at hand, I think it closely related to issue #709

As mentioned above, some component in your project is initializing SLF4J without calling the ch.qos.logback.classic.LogerContext.setMDCAdapter() method. Versions of logback prior to 1.3.8 will not suffer from the problem you describe here.

Without further information, I am closing this issue with NOT_A_BUG and WONT_FIX.

[sjmuir]

Changing to the top-left diagram resolved the issue thanks. I still think it would be better to detect the null pointer and report the issue somehow rather than just let the NullPointerException happen.