Upgrades Logback from 1.5.6 to 1.5.7.
The return type of ch.qos.logback.core.ContextBase#getConfigurationLock.getConfigurationLock() has changed from java.lang.Object to java.util.concurrent.locks.ReentrantLock. It's noteworthy that this is a source compatible, binary incompatible change. The change necessitates replacing a synchronized block with a try-finally construct to ensure correct locking semantics going forward. There were also changes to the behavior of ch.qos.logback.classic.LoggerContext#stop() that necessitate calling ch.qos.logback.classic.LoggerContext#reset() where it wasn't already, in tests.
Closes #41887
Comment From: snicoll
Thanks @mches. I was looking at this and noticed this PR. Our build is broken with just a change of version, namely profiles don't seem to work anymore. I've kicked off a build for this PR to see if your changes make a difference.
Comment From: mches
@snicoll You're welcome. I had a lot of fun figuring out why it broke. The build works great locally. 🤞🏻
Comment From: snicoll
Thanks very much @mches. A timely PR indeed!
Comment From: wilkinsona
Unfortunately, we're going to have to revert this. In Logback 1.5.6 and earlier, stopping the LoggerContext would reset it. In 1.5.7, it only does so if it has been started. We're stopping a context that hasn't been started so reset isn't called. This PR addresses this by calling reset explicitly in some tests, but this doesn't address the issue that the LoggerContext is in the wrong state and may be hiding other bugs that occur due to that. We've seen these in our CI jobs on Windows which fail as the log file is left open and deleting it fails. We need to review how we're managing the lifecycle of the LoggerContext and make sure that it's in the right state. I will use #41887 to do that.