Support for com.lmax:disruptor:4

[ashr123]

Description

When I run with async logger and com.lmax:disruptor:4, I get the following error:

Exception in thread "main" java.lang.NoClassDefFoundError: com/lmax/disruptor/SequenceReportingEventHandler
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1027)
	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	at org.apache.logging.log4j.core.async.AsyncLoggerConfigDisruptor.start(AsyncLoggerConfigDisruptor.java:226)
	at org.apache.logging.log4j.core.config.AbstractConfiguration.start(AbstractConfiguration.java:312)
	at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:621)
	at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:694)
	at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:711)
	at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:253)
	at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:155)
	at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:47)
	at org.apache.logging.log4j.LogManager.getContext(LogManager.java:196)
	at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:599)
	at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:585)
	... 1 more
Caused by: java.lang.ClassNotFoundException: com.lmax.disruptor.SequenceReportingEventHandler
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	... 21 more

Configuration

{
  "Configuration": {
    "Appenders": {
      "Console": {
        "name": "Console-Appender",
        "target": "SYSTEM_ERR",
        "PatternLayout": {
          "pattern": "%d{DEFAULT} [%level] - %msg%n"
        }
      },
      "Async": {
        "name": "Async-Console-Appender",
        "AppenderRef": {
          "ref": "Console-Appender"
        },
        "LinkedTransferQueue": {}
      }
    },
    "Loggers": {
      "AsyncRoot": {
        "level": "INFO",
        "AppenderRef": {
          "ref": "Async-Console-Appender"
        }
      }
    }
  }
}

Version: 2.20.0
Operating system: MacOS 13.6
JDK: OpenJDK 21

Reproduction

Just run an Java class with the following static field:

private static final Logger LOGGER = LogManager.getLogger();

[vy]

@ashr123, yes, it is sadly a known problem. See LOG4J2-3595 that was reported earlier. We would appreciate it if you can submit a PR fixing the issue.

[jvz]

@vy I think it's harder to notice old Jira issues since we've migrated to GitHub Issues

[vy]

@jvz, feel free to mark the JIRA one as duplicate and re-open this one.

[jvz]

Looks like this should be pretty simple to update. The main breaking change to handle here is updating some EventHandler implementations to directly implement that interface rather than using some mixin interfaces for the same. Nice simplification in the API actually!

[ppkarwasz]

@tcmot,

We support JPMS, which prevents two different modules from having the same classes.

However the differences between Disruptor 3.x and 4.x reduce themselves to having some optional classes in 3.x and we have a lot of experience dealing with optional dependencies. This issue is on my TODO list for 2.23.0 (January/February), but you can provide a PR following the guideline I provided in #1856.

[tcmot]

Hi @ppkarwasz

3.44 to 4.0.0

1,public class RingBufferLogEventHandler implements SequenceReportingEventHandler<RingBufferLogEvent>, LifecycleAware {

2,public class RingBufferLogEventHandler implements EventHandler<RingBufferLogEvent> {

Change 1 to 2, will complete the upgrade.

[tcmot]

Log4j2 version: 2.22.0

[ppkarwasz]

@tcmot,

If you do that log4j-core stops working with version 3.x of Disruptor.

In the 2.x branch of Log4j the baseline is JRE 8 and will be for a long time. Therefore the baseline for LMAX Disruptor must be 3.x (Disruptor 4.x requires JRE 11). Since it is fairly easy to support both Disruptor 3.x and Disruptor 4.x, I will vote against any PR that does not work with Disruptor 3.x.

[ashr123]

What about moving to JDK 17 or 21?

[ppkarwasz]

@ashr123,

The baseline for Log4j 3.x is JRE 17.

[ashr123]

is there a chance to move Log4J 4 to JDK 21? of not, what are the considerations?

[ppkarwasz]

@ashr123,

Every version of Log4j (both 2.x and 3.x) runs on the newest Java available.

By baseline I only mean the oldest supported JRE. This is a restriction only for maintainers: in the 2.x branch we can not use language constructs or library methods from JDK 11+. Users don't feel this restriction, since we can use multiple techniques (e.g. Multi-Release JARs, reflection, etc.) to guarantee the log4j-core works in the same way on all the JDKs.

[ashr123]

I've asked only because it will allow you to use the newest features of the language and maybe make it more efficient (for example by using virtual threads, switch patterns etc)

[ppkarwasz]

@ashr123,

We already compile our versions with JDK 17 (targeted at JRE 8 code), so many improvements in the compiler are already present.
Regarding virtual threads check LOG4J2-3622