Parent first dependencies method in Class Loading Reference guide not working for applications

[galderz]

Describe the bug

A Quarkus application that wants to use byteman to intercept and startup and shutdown events will suffer issues like this with default fast-jar.

On startup, byteman is loaded with the system classloader and it successfully injects the rule:

[1830908236 null] Rule.execute called for restore_1:0
HelperManager.install for helper class org.acme.JigawattsService
calling activated() for helper class org.jboss.byteman.rule.helper.Helper
Default helper activated
calling installed(restore) for helper classorg.jboss.byteman.rule.helper.Helper
Installed rule using default helper : restore
calling activated() for helper class org.acme.JigawattsService
Default helper activated
calling installed(restore) for helper classorg.acme.JigawattsService
Installed rule using default helper : restore
restore execute()
Restore::entry
Restore::exit

Then on shutdown, the rule won't trigger and you will see these messages appearing on byteman:

^C[33293669 io.quarkus.bootstrap.runner.RunnerClassLoader@3d24753a] Rule.execute called for checkpoint_0:0
Rule.execute for decommissioned key checkpoint_0:0

What is happening is that on shutdown, byteman classes are being loaded with a different classloader (the RunnerClassLoader). This is problematic because Byteman's rule has a static cache of rules, and when the class is loaded with another classloader different to the system one, the cache is empty and it won't trigger the rule. The above (tweaked) byteman log messages show that.

The classloading guide indicates how to avoid this issue in the parent first dependencies section. The guide suggests to do add this to the pom.xml but for Quarkus applications (not extensions) it has no effect:

<plugin>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-extension-maven-plugin</artifactId>
    <configuration>
        <parentFirstArtifacts>
            <parentFirstArtifact>org.jboss.byteman:byteman</parentFirstArtifact>
        </parentFirstArtifacts>
    </configuration>
</plugin>

However, if you instead modify the app's application.properties file and add this:

quarkus.class-loading.parent-first-artifacts=org.jboss.byteman:byteman

Then things will work:

^C[1288354730 null] Rule.execute called for checkpoint_0:0
HelperManager.install for helper class org.jboss.byteman.rule.helper.Helper
calling installed(checkpoint) for helper classorg.jboss.byteman.rule.helper.Helper
Installed rule using default helper : checkpoint
checkpoint execute
Checkpoint::entry

What you're seeing above is the rule being loaded with the system classloader once again and things working as expected.

Documentation should make this clear.

Moreover, the following statement in the classloader guide is outdated:

When running a production application everything is loaded in the system ClassLoader, so it is a completely flat class path.

There should be an explanation about fast-jar (vs legacy-jar)...etc.

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response

[galderz]

One more thing. Quarkus code should be improved. A user shouldn't have to do any of this. Quarkus should not make it harder for tools like Byteman to be used with it. IOW Quarkus should hardcode byteman to be parent first class loaded.

[quarkus-bot]

/cc @Sanne, @aloubyansky, @gsmet, @radcortez, @stuartwdouglas

[geoand]

@galderz mind taking a look at #29053?

[galderz]

Thx @geoand!

[geoand]

🙏🏼