Fix log duplication we experienced in Jenkins when testing RHBQ 3.8

[michalvavrik]

Summary

For context, this is current state:

• We use everywhere java.util.logging.Logger. Even in Quarkus QE Test Suite, despite setting https://github.com/quarkus-qe/quarkus-test-suite/blob/331864b32bfd821b12e87d8919b54492078edbb9/pom.xml#L223 because that's a surefire, but we run almost all of the tests with the failsafe plugin.
  • This is demonstrated by following logged message logged in every test of ours:
    The LogManager accessed before the "java.util.logging.manager" system property was set to "org.jboss.logmanager.LogManager". Results may be unexpected.
  • The error message is produced by JBOSS LogManager https://github.com/jamezp/jboss-logmanager/blob/5f444f8cc651c6bb491f7d8275dea46cebb0b65d/src/main/java/org/jboss/logmanager/JBossLoggerFinder.java#L76 and in our context it means (I translated it):
    • you try to use our log handlers ConsoleHandler and FileHandler
    • you use java.util.logging.Logger
    • we add these handlers to the logger, but the JBoss LogManager is not default in the system
• When RHBQ is run on RHEL with our FW, for some reason, the system property java.util.logging.manager is indeed set org.jboss.logmanager.LogManager. It is specific for our FW, I cannot reproduce it with vanialla Quarkus. Invested few hours into it but it's waste of time. I don't care why for following reasons:
  • it cannot be reproduced without FW
• We have following 2 log handlers configured by every test of ours:
  • Console handler: https://github.com/quarkus-qe/quarkus-test-framework/blob/main/quarkus-test-core/src/main/java/io/quarkus/test/logging/Log.java#L109
  • File handler:

    quarkus-test-framework/quarkus-test-core/src/main/java/io/quarkus/test/logging/Log.java

    Line 117 in 855fe3c

    FileHandler file = new FileHandler(

• the 2 handlers are added to the java.util.logging.Logger

What issue do we have:

• In the special case (when RHBQ is run on RHEL by our FW) the Jboss console handler is applied in addition to the

  quarkus-test-framework/quarkus-test-core/src/main/java/io/quarkus/test/logging/Log.java

  Line 53 in 855fe3c

  private static final Logger LOG = Logger.getLogger(Log.class.getName());

  and we get everything twice because both io.quarkus.bootstrap.logging.QuarkusDelayedHandler and org.jboss.logmanager.handlers.ConsoleHandler are logging console output.
  • the io.quarkus.bootstrap.logging.QuarkusDelayedHandler doesn't seem to be present in other cases

What has changed:

• my bet is on Switch to jboss-logmanager quarkusio/quarkus#33318 because 3.2 is not affected (I run tests, couldn't reproduce it so far)
• I won't investigate more unless I am aware of a scenario when Quarkus is affected, not just our FW, and I am not aware about just scenario ATM

Proposed solution:

• drop the io.quarkus.bootstrap.logging.QuarkusDelayedHandler handler
  • this can be done only if JBoss Console handler is in place, but I am doing it always as what is the point of adding system property check for java.util.logging.manager as we know it's not going to be there
  • because the io.quarkus.bootstrap.logging.QuarkusDelayedHandler is not in place when the java.util.logging.manager is not set to the org.jboss.logmanager.LogManager because it is only added here https://github.com/quarkusio/quarkus/blob/089dafbed78b0f1124a97e9cd87a60a05304477e/independent-projects/bootstrap/runner/src/main/java/io/quarkus/bootstrap/logging/InitialConfigurator.java#L56 which is Jboss Log Manager specific context

This PR is backwards compatible and it will fix log duplications even if we don't use Jboss Log Manager.

Please check the relevant options

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Dependency update
• Refactoring
• Release (follows conventions described in the RELEASE.md)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update
• This change requires execution against OCP (use run tests phrase in comment)

Checklist:

• Example scenarios has been updated / added
• Methods and classes used in PR scenarios are meaningful
• Commits are well encapsulated and follow the best practices

[michalvavrik]

Failures are unrelated; #1299 should take care of them

[michalvavrik]

hey @mjurc, @rsvoboda is processing 3.8, maybe you could review instead?

[michalvavrik]

I'll rebase on current main to get CI green.

[mjurc]

LGTM, let's see if this helps :)