Provide option to re-enable log4j2 JMX support when they disable it by default

[sdavids]

configurations {
  implementation {
    exclude(module = "spring-boot-starter-logging")
  }
}

dependencies {
  implementation("org.springframework.boot:spring-boot-starter")
  implementation("org.springframework.boot:spring-boot-starter-log4j2")
  testImplementation("org.springframework.boot:spring-boot-starter-test")
}

package com.example.demo;

import org.junit.jupiter.api.Test;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.jmx.support.MBeanServerFactoryBean;

import static org.assertj.core.api.Assertions.assertThat;

@SpringBootTest
class DemoApplicationTests {

  @Test
  void contextLoads() {
    var factory = new MBeanServerFactoryBean();
    factory.setLocateExistingServerIfPossible(true);
    factory.afterPropertiesSet();
    var server = factory.getObject();
    assertThat(server.getDomains()).doesNotContain("org.apache.logging.log4j2"); // fails
  }
}

JMX support is enabled by default.

https://logging.apache.org/log4j/2.x/manual/jmx.html#enabling-jmx

Related

Spring Boot - Disable JMX by default

JUnit 5 - Disable Log4J JMX beans creation in tests

---

Ideally the auto-configuration would set log4j2.disableJmx=true if spring.jmx.enabled=false thereby no log4j2 JMX beans would be created.

Alternatively, the log4j2.disableJmx property should be mentioned in at least these two places:

• Log4j2 System Properties
• Monitoring and Management over JMX

[philwebb]

I think we might want to do something here, but I'm not sure we should tie things with spring.jmx.enabled since that property is really supposed to turn off Spring specific JXM features.

I wonder if we should wait to see how https://github.com/apache/logging-log4j2/issues/1229 plays out. If Log4J flip the default then we might be able to provide a quick way to turn it back on for users that need it.

[wilkinsona]

Log4j2 has flipped the default so we can consider an option to flip it back as and when we upgrade to a version with the change. That said, I learned from https://github.com/apache/logging-log4j2/pull/2468#pullrequestreview-1999738929 that Log4j 3.0 won't have any JMX support at all so I wonder if this is really worth it. The log4j2.disableJmx=false system property will be available irrespective of what we do here.

[sdavids]

I suggest having no code changes but a documentation improvement.

---

https://docs.spring.io/spring-boot/reference/actuator/jmx.html

Add something along the lines of:

[NOTE]
====
`spring.jmx.enabled` affects only the management beans provided by Spring.

The enablement of management beans provided by other frameworks, e.g. https://logging.apache.org/log4j/2.x/manual/jmx.html[Log4j2], https://www.quartz-scheduler.org/api/2.3.0/constant-values.html#org.quartz.impl.StdSchedulerFactory.PROP_SCHED_JMX_EXPORT[Quartz], or https://docs.jboss.org/hibernate/orm/5.2/userguide/html_single/appendices/Configurations.html#configurations-jmx[Hibernate], is independent.
====

---

https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.core.spring.jmx.enabled

Expose management beans to the JMX domain.

⇓

Expose Spring's management beans to the JMX domain.

[ppkarwasz]

@wilkinsona,

Log4j2 has flipped the default so we can consider an option to flip it back as and when we upgrade to a version with the change. That said, I learned from apache/logging-log4j2#2468 (review) that Log4j 3.0 won't have any JMX support at all so I wonder if this is really worth it. The log4j2.disableJmx=false system property will be available irrespective of what we do here.

I think it would make sense for a Spring Application to use !spring.jmx.enabled as default value for log4j2.disableJmx regardless of the version of Log4j Core used. Adding the appropriate logic to SpringEnvironmentPropertySource should be enough to accomplish this.

There are not many users that use Log4j JMX, there are probably even less users that enable JMX in Log4j, but not in Spring Boot, so it might even be safe to do it in a patch release.