Named logger issues - "Handler with name is linked to a category but not configured."

[jcjveraa]

Hi there,
When I configure a logger in Quarkus 3.15.2 + quarkus-logging-splunk 4.0.2 we see some inconsistent behavior.

When setting it up per the docs (as far as I see), we get error logs on stderr from Quarkus stating LogManager error of type GENERIC_FAILURE: Handler with name 'MyLogger' is linked to a category but not configured. However, it works fine: the logs are ending up in Splunk as expected.

quarkus:
  log:
    handler:
      splunk:
        enabled: false
        "MyLogger":
          token: ${SPLUNK_TOKEN} 
          url: ${SPLUNK_URL}
          serialization: raw
          format: "%d{yyyy-MM-dd HH:mm:ss,SSS} %s%e%n"
          async: true
          max-retries: 256
  log:
    category:
      "splunkLog":
        handlers: "MyLogger"

When I add a similarly named Console logger, the error goes away - but then it sends all logging to Splunk, also the logs that just should go to the console.

quarkus:
  log:
    handler:
      console:
        "MyLogger":
          enabled: true

It seems Quarkus is not picking up on the fact that the splunk logger has registered a named logger and the LogManager error is wrong?

[jcjveraa]

To just randomly try a few things, I've tried a downgrade to 3.3.2 but that doesn't matter. Adding use-parent-handlers: false neither makes a difference.

[rquinio1A]

Indeed I can reproduce the stderr line with https://github.com/quarkiverse/quarkus-logging-splunk/blob/main/deployment/src/test/java/io/quarkiverse/logging/splunk/LoggingSplunkNamedHandlerConfigTest.java
It's also happening in older branches with Quarkus 3.8 & 3.2, not just main.

I suspect it's a limitation of Quarkus when named handlers are created from an extension using NamedLogHandlersBuildItem, as the core log handlers don't use this mechanism.
I'll report an issue upstream.

[jcjveraa]

Thanks for the swift response! This is work related and I was enjoying my weekend, hence my slower reply. For me this closes the issue assuming it will at some point work without spurious logging, but I’ll leave it up to you as maintainers to either close this or keep it open for tracking.

Regards,
Jelle

[rquinio1A]

@jcjveraa Let's keep it open until it's fixed upstream, to avoid duplicate reports.