ComponentInstallers should run after LogManager regardless of Java version/JFR presence

[mateuszrzeszutek]

Describe the bug
I've spent a few hours debugging an issue happening on openj9 (IBM) JVM & WildFly where the following exception would happen:

java.lang.IllegalStateException: WFLYLOG0078: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager. The subsystem has not be initialized and cannot be used. To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"

It turns out that in AgentInstaller#installComponentsAfterByteBuddy() the agent decided to run the component installers directly, not asynchronously, because JFR is not present on the classpath (JDK <= 8 & custom LogManager conditions passed).
Then in our splunk distro we had a custom ComponentInstaller that tried to initialize some metrics and used a javax.management.NotificationEmitter -- which indirectly uses JUL, so it initialized LogManager, which of course couldn't find the JBoss LogManager in the AgentClassLoader and defaulted to the JVM implementation. And then the error happened.

I believe that this might become a problem in the future for the vanilla OTel javaagent too, once we implement more standard JVM metrics (that call javax.management classes).

To solve this I think that we should remove the jdk <= 8 && containsJfr check and only leave the custom LogManager one. The JFR stuff (JMXFetch?) is clearly copied from the DD agent and doesn't make sense in OTel javaagent.

Environment
Java 1.8.0_282. JVM Eclipse OpenJ9 VM - Eclipse OpenJ9 - openj9-0.24.0

Additional context
This is pretty similar to #2546, who knows, maybe the simplified condition will fix it too

[trask]

just a heads up on another problem (besides j.u.l.) with using PlatformMBeanServer too early 😭

https://github.com/glowroot/glowroot/blob/29114b2cabe5115cd39a50774039f8bdf99a5f31/agent/core/src/main/java/org/glowroot/agent/util/LazyPlatformMBeanServer.java#L118-L119

(this was supporting Java 6+, so possibly the situation is better now?)

[mateuszrzeszutek]

(this was supporting Java 6+, so possibly the situation is better now?)

I have no idea, we probably won't know unless something fails on this 🙈