Hi @verjan-isencia,

Thank you for reporting this issue.

This appears to be a composite problem caused by two factors:

1. In version 2.23.0, we introduced support for Disruptor 4, while still maintaining compatibility with Disruptor 3—the last major version that supports our Java 8 baseline. However, the tool we use to generate the OSGi manifest assumes by default that only one major version of each dependency is supported. As a result, we forgot to explicitly override this and set the supported version range for Disruptor to [3.4,5). This will be corrected in Fixes OSGi descriptor to accept Disruptor 4 #3707.

2. To work around breaking changes in Disruptor 4, we use reflection to load the appropriate class for the detected version:
   

   logging-log4j2/log4j-core/src/main/java/org/apache/logging/log4j/core/async/DisruptorUtil.java

   Lines 53 to 54 in 49cdf74

   	static final int DISRUPTOR_MAJOR_VERSION =
   	LoaderUtil.isClassAvailable("com.lmax.disruptor.SequenceReportingEventHandler") ? 3 : 4;

   Unfortunately, this detection fails in your environment and incorrectly identifies your Disruptor version as 4.x. We have not been able to reproduce this issue in our PAX Exam 4 tests with either Equinox or Felix.

Could you please provide more details about your OSGi environment? A minimal reproducible example would be especially helpful.

I have been debugging the problem in our OSGI platform, and the problem seems to be with the classloader used at the moment the static variable in DisruptorUtil is initialized:

    static final int DISRUPTOR_MAJOR_VERSION =
            LoaderUtil.isClassAvailable("com.lmax.disruptor.SequenceReportingEventHandler") ? 3 : 4;

Inside LoaderUtil, the classloader is chosen with which to call Class.forName("com.lmax.disruptor.SequenceReportingEventHandler") and it ends up using the ThreadContextClassLoader. Problem is that in our case that happens to be the org.apache.aries.cdi.container.internal.loader.BundleClassLoader (because we need support for CDI at some point in the application), and that classloader does not appear to see any classes of the disruptor bundle.

The problem would be fixed using the bundle classloader of the disruptor bundle (f.e. com.lmax.disruptor.EventHandler.class.getClassLoader()). If not, I suppose I could try to find a way to get the version initialized earlier in the startup process.

Also noticing that SequenceReportingEventHandler appears to also be available in Disruptor version 3.4.4. Otherwise, the general patch here for DisruptorUtil looks something like:

    static final int DISRUPTOR_MAJOR_VERSION = calculateDisruptorMajorVersion();

    static int calculateDisruptorMajorVersion() {
        final ClassLoader classLoader = EventHandler.class.getClassLoader();
        try {
            Class.forName("com.lmax.disruptor.SequenceReportingEventHandler", true, classLoader);
            return 4;
        } catch (final ClassNotFoundException | LinkageError e) {
            return 3;
        }
    }

Also noticing that SequenceReportingEventHandler appears to also be available in Disruptor version 3.4.4.

Yes, it is available in version 3.x, but not in version 4.x. In version 4.x the EventHandler interface hierarchy was flattened.