I'll expand on my previous JIRA comment to include your analysis:

Issue most likely is with isClassAvailable method causing FusionReactor compatibility problems

Problem:

The isClassAvailable method is failing to detect the existence of the FusionReactor injected class java.management.fusionreactor.Management. This causes a NoClassDefFoundError when the Lucee runtime attempts to use FusionReactor with FW/1 applications.

Analysis:

• The current implementation of isClassAvailable uses loader.getResource(resourcePath) to check for class existence, which is more efficient than catching ClassNotFoundException exceptions

• However, this approach fails with dynamically injected classes like java.management.fusionreactor.Management

• The class can be successfully loaded with loadClass() but isn't discoverable via getResource()

• This issue only appeared after recent changes to our classloader hierarchy (after version 6.2.0.248)

Root Cause:

The issue appears to be twofold:

1. As previously identified, the changes in our classloader hierarchy between 6.2.0.248 and newer versions have altered how external classes are loaded. The PhysicalClassLoader in 248 could see the FusionReactor class, but in newer versions it cannot, because it is not part of the SystemClassloader.

2. The isClassAvailable method itself is problematic for dynamically injected classes. It uses getResource() to check for class existence, but this method fails for classes that are injected at runtime by agents like FusionReactor. While loadClass() can successfully load these classes, getResource() cannot find them because they don't exist as resources in the normal classpath.

The unusual naming pattern with "java.management" prefix might be intended to leverage OSGi class loading behavior, but our changes have affected this mechanism.

Temporary Solution:

I've temporarily disabled the isClassAvailable optimization and reverted to using loadClass() as before. This resolves the immediate compatibility issue with FusionReactor while we work on a more targeted solution.

https://github.com/lucee/Lucee/commit/c25cd91f079eb2617f144caadd1038015dbd86e1

After extensive debugging with @Zac Spitzer , I've identified the possible root cause of the NoClassDefFoundError: java/management/fusionreactor/Management issue.

Analysis:

1. The error occurs only in CommandBox environments with FW/1 framework, while it works fine in Express/standalone Lucee deployments.

2. The issue starts appearing after Lucee 6.2.0.249, suggesting a change in the classloader behavior.

3. When I added debug logging to the PhysicalClassLoader, I observed the system is attempting to load java.management.fusionreactor.Management and loads it by the super Classloader from PhysicalClassloader .

4. I confirmed the class exists in the FusionReactor installation (fr-management.jar in the FusionReactor directory), but our classloader changes have affected its visibility (i guess).

5. The problematic class has an unusual naming pattern with "java.management" prefix, which suggests it might be intended to leverage OSGi class loading behavior.

Root Cause:

The changes in our classloader hierarchy between 6.2.0.248 and newer versions have altered how external classes are loaded. The PhysicalClassLoader in 248 could see the FusionReactor class, but in newer versions it cannot, because it is not part of the SystemClassloader.

The class is likely not being loaded because it's not in the OSGi bootdelegation list, despite having a "java" prefix, what only benefit classes from the system classloader.

Next Steps:

I'll add the java.management.fusionreactor package explicitly to our default.properties bootdelegation list to ensure the class is properly delegated to any classloader when available.

This should at least get rid of this exception and maybe break further down the road, but this will confirm the above assumptions.

with 6.2.0.248 we see the following on the console:

but it works

I’ll shoot an email to the FusionReactor support team to see if they can take a look. I pinged them in the CFML slack channel as well.

@Zac Spitzer @Matthew Clemente problem is that fusionreactor injects code into the Lucee bytecode via a java agent, that seems to fail, question is how that code looks like

The error stack trace shows FusionReactor attempting to instrument Lucee's bytecode at runtime, which is failing when looking for the non-existent class java/management/fusionreactor/Management. The agent is likely attempting to insert monitoring hooks into the application startup process.

The injection pattern can be seen in the stack trace where FusionReactor components (WrappedFilterChain, FusionReactorRequestHandler, etc.) are intercepting the request flow. The specific bytecode manipulation is probably attempting to add performance monitoring around method calls but is referencing an incorrect or missing class.