Issue can be reproduced using spring-boot-sample-logback and the following patch (Logback 1.1.6 is required to avoid NPE on reloadDefaultConfiguration, see qos-ch/logback#302):

diff --git spring-boot-samples/spring-boot-sample-logback/pom.xml spring-boot-samples/spring-boot-sample-logback/pom.xml
index 34efcd6..836a052 100644
--- spring-boot-samples/spring-boot-sample-logback/pom.xml
+++ spring-boot-samples/spring-boot-sample-logback/pom.xml
@@ -17,6 +17,7 @@
        </organization>
        <properties>
                <main.basedir>${basedir}/../..</main.basedir>
+               <logback.version>1.1.6</logback.version>
        </properties>
        <dependencies>
                <dependency>
diff --git spring-boot-samples/spring-boot-sample-logback/src/main/java/sample/logback/SampleLogbackApplication.java spring-boot-samples/spring-boot-sample-logback/src/main/java/sample/logback/SampleLogbackApplication.java
index 058fe1a..8569507 100644
--- spring-boot-samples/spring-boot-sample-logback/src/main/java/sample/logback/SampleLogbackApplication.java
+++ spring-boot-samples/spring-boot-sample-logback/src/main/java/sample/logback/SampleLogbackApplication.java
@@ -16,21 +16,22 @@

 package sample.logback;

-import javax.annotation.PostConstruct;
-
 import org.slf4j.Logger;
 import org.slf4j.LoggerFactory;

 import org.springframework.boot.SpringApplication;
 import org.springframework.boot.autoconfigure.SpringBootApplication;
+import org.springframework.scheduling.annotation.EnableScheduling;
+import org.springframework.scheduling.annotation.Scheduled;

+@EnableScheduling
 @SpringBootApplication
 public class SampleLogbackApplication {

        private static final Logger logger = LoggerFactory
                        .getLogger(SampleLogbackApplication.class);

-       @PostConstruct
+       @Scheduled(fixedDelay = 5000)
        public void logSomething() {
                logger.debug("Sample Debug Message");
                logger.trace("Sample Trace Message");
diff --git spring-boot-samples/spring-boot-sample-logback/src/main/resources/logback-spring.xml spring-boot-samples/spring-boot-sample-logback/src/main/resources/logback-spring.xml
index e279b82..638b4c4 100644
--- spring-boot-samples/spring-boot-sample-logback/src/main/resources/logback-spring.xml
+++ spring-boot-samples/spring-boot-sample-logback/src/main/resources/logback-spring.xml
@@ -1,5 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <configuration>
+       <jmxConfigurator/>
        <include resource="org/springframework/boot/logging/logback/base.xml" />
        <logger name="sample.logback" level="DEBUG" />
        <springProfile name="staging">

Start the sample app, execute reloadDefaultConfiguration operation via JMX. The following output is logged:

21:33:08,445 |-INFO in ch.qos.logback.classic.jmx.JMXConfigurator(default) - Resetting context: default
21:33:08,445 |-INFO in ch.qos.logback.classic.jmx.JMXConfigurator(default) - onReset() method called JMXActivator [ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator]

After that no further events are logged.

The problem is that there's no LoggerContextListener that would've notified logging system of reset operation and trigger the re-initialization.

Comment From: vpavic

Any feedback on this issue?

Comment From: philwebb

Supporting JXM logback reloading isn't something we've looked at. It would be a nice addition but it's not very high on the list at the moment.

Comment From: philwebb

Mind you, you make some compelling points in your comments on #5321

Comment From: vpavic

I'll try to take a more detailed look at this and come up with PR.

Comment From: philwebb

Thanks!

Comment From: vpavic

The cleanest way to fix this is to provide customized JMXConfigurator which hooks into LogbackLoggingSystem for reloadDefaultConfiguration and reloadByFileName operations. This is the approach I took in #4486.

Fixing this without adding without automatically registering JMXConfigurator would require replacing the default JMXConfiguratorAction with a custom one that registers previously mentioned customized JMXConfigurator (instead of the original one) when <jmxConfigurator/> is used in Logback configuration.

Comment From: philwebb

We're cleaning out the issue tracker and closing issues that we've not seen much demand to fix. Feel free to comment with additional justifications if you feel that this one should not have been closed.

Comment From: DotsenkoMax

So, what about this topic? Had it been solved? Or it is still no way to "set/get" logback logging lvl in runtime via jmx?

Comment From: wilkinsona

You can set log levels via JMX using the Actuator's loggers endpoint. If you have any further questions, please follow up on Stack Overflow or Gitter. As mentioned in the guidelines for contributing, we prefer to use GitHub issues only for bugs and enhancements.

Comment From: vpavic

The problem I see is that Actuator endpoint is proprietary to Spring Boot, whereas if I'm using Logback as my preferred logging solution regardless of the stack, I'd like to align tooling/scripts against the whatever is the common thing - and that would be Logback's JMX.

Additionally, this issue was specifically focused on reloadDefaultConfiguration operation that Logback JMX conveniently offers, which I personally still find very useful after fiddling with logger levels on a live env because I'd like to be able to restore the original configuration without too much hassle, like tracking every change made and reverting them individually.

For anyone affected by this, the workaround that provides a configuration that as close as possible to Spring Boot's defaults while also ensuring reloadDefaultConfiguration JMX operation works a is to provide logback.xml like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <jmxConfigurator/>
    <include resource="org/springframework/boot/logging/logback/base.xml"/>
</configuration>

The downside of using logback.xml instead of logback-spring.xml is that you lose out on some features, as documented in 4.8. Custom Log Configuration and 4.9. Logback Extensions sections of the reference manual.

If there's no intention to ever make reloadDefaultConfiguration work in a Spring Boot managed logging setup, I'd suggest to at the very least document this as a known shortcoming.

Comment From: wilkinsona

@vpavic Nobody is disputing any of that. I was responding to a specific question about getting and setting log levels:

Or it is still no way to "set/get" logback logging lvl in runtime via jmx?

Any changes around configuration reloading via JMX remain blocked by https://jira.qos.ch/browse/LOGBACK-1371.

Comment From: vpavic

@wilkinsona I wasn't aware this is considered blocked, given the issue was closed and labeled as declined.

Comment From: snicoll

@vpavic the logback issue is open with no feedback for more than three years. Going back to your comment, please consider the root of the message going forward: we can't implement this and I personally don't think it's very helpful to have an open issue on our side if there is no indication that there is progress on something that we're blocked on.