On using custom SLF4JServiceProvider

[reaver585]

Howdy folks,

We recently migrated our backend from WildFly to Quarkus. The transition was smooth, Quarkus is running reliably, and while our primary drivers were improved developer experience, observability, and ease of upgrades, we also observed a performance boost - which was a nice bonus. Kudos to everyone involved in building and maintaining Quarkus - it's a solid framework.

Now, here's the issue I'm trying to solve:
Is it possible to register a custom SLF4JServiceProvider that works consistently in both dev and production modes?

We have custom logging requirements that we currently meet by implementing a custom SLF4J provider. This works as expected in production mode, but in dev mode, the provider is ignored.

Here's a minimal reproducer using Gradle:
https://github.com/reaver585/quarkus-and-logging/tree/main
In this setup, the SLF4J service provider is ~99% copied from slf4j-jboss-logmanager.

When I build the app via ./gradlew :server:build and run it with java -jar server/build/quarkus-app/quarkus-run.jar, Quarkus correctly discovers both the custom implementation and the default slf4j-jboss-logmanager:

SLF4J: Class path contains multiple SLF4J providers.
SLF4J: Found provider [org.slf4j.impl.CustomJbossSlf4jServiceProvider@38bd077e]
SLF4J: Found provider [org.slf4j.impl.JBossSlf4jServiceProvider@ddf1df9]
SLF4J: See https://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual provider is of type [org.slf4j.impl.CustomJbossSlf4jServiceProvider@38bd077e]

The duplicate provider issue can be resolved by excluding the default SLF4J binding in server/build.gradle:

configurations {
    configureEach {
        exclude group: 'org.jboss.slf4j', module: 'slf4j-jboss-logmanager'
    }
}

However, when running in dev mode via ./gradlew quarkusDev, the custom provider is completely ignored. I suspect this is due to how Quarkus handles classloading in dev mode - specifically the use of QuarkusClassLoader.

So, is there a recommended approach to get a custom SLF4JServiceProvider working in dev mode?

I understand that Quarkus enforces JBoss LogManager as the underlying logging backend (1, 2). However, the fact that a custom SLF4J provider works in production suggests that alternative implementations are technically viable - at least in prod mode - via the SLF4J SPI.

For additional context: we need precise control over how stack traces are printed in logs, as this impacts how our cloud-based error reporting platform parses and groups exceptions. One might suggest implementing a custom LogConsoleFormatBuildItem or LogHandlerBuildItem via a Quarkus extension, but those APIs expose a LogRecord where exception details are already rendered into the log message. Since our codebase consistently uses log.error("msg", e) through SLF4J, we need earlier control over how exceptions are formatted.

Any guidance or best practices for handling this in dev mode would be greatly appreciated.

And one bonus question I have is: is there any mechanism that allows one to specify dependencies that should be loaded by QuarkusClassLoader? If not, is there any plan to introduce such a mechanism?

If any of this sounds like a bug or design gap, I’d be happy to contribute and help fix it - assuming you think it makes sense.

Thanks in advance.

[aloubyansky]

Thanks for reporting the issue with a reproducer. The first thing to try (as a workaround) would be to use the customer logging provider as an external dependency instead of a subproject.

[reaver585]

Thanks @aloubyansky. I did try what you proposed, you can reproduce it in branch alt/try-with-external-dependency: https://github.com/reaver585/quarkus-and-logging/pull/1/files

To reproduce:

1. cd logging
2. mvn clean install
3. Run dev mode for :server (same as on main branch, using ./gradlew :server:quarkusDev
4. Compare with production: ./gradlew :server:build && java -jar server/build/quarkus-app/quarkus-run.jar
5. Observe different logging behaviour.

So unfortunately it's still same. Bear in mind though, that I'm not a maven guy so there is a chance I could've messed something up in logging/pom.xml.

Thanks in advance.

[dmlloyd]

Howdy folks,

We recently migrated our backend from WildFly to Quarkus. The transition was smooth, Quarkus is running reliably, and while our primary drivers were improved developer experience, observability, and ease of upgrades, we also observed a performance boost - which was a nice bonus. Kudos to everyone involved in building and maintaining Quarkus - it's a solid framework.

Now, here's the issue I'm trying to solve: Is it possible to register a custom SLF4JServiceProvider that works consistently in both dev and production modes?

This is generally not supported. Also, only a fraction of the log messages in Quarkus pass through the SLF4J API, so depending on what you're doing, it might not work as well as you expect in practice.

For additional context: we need precise control over how stack traces are printed in logs, as this impacts how our cloud-based error reporting platform parses and groups exceptions. One might suggest implementing a custom LogConsoleFormatBuildItem or LogHandlerBuildItem via a Quarkus extension, but those APIs expose a LogRecord where exception details are already rendered into the log message. Since our codebase consistently uses log.error("msg", e) through SLF4J, we need earlier control over how exceptions are formatted.

The LogRecord (actually ExtLogRecord in Quarkus) does not render a log message. You still have direct access to every aspect of the log event and can render it however you wish.

The role of the Handler is to determine how log messages are processed (often by formatting the message to a file, but this is only one possibility). The Formatter is used for handlers which render a LogRecord into text (and only such handlers).

You should be able to do anything you need to by implementing one or the other of these, since no information is lost between the log method and the handler (unless the log message is filtered out by configuration).

And one bonus question I have is: is there any mechanism that allows one to specify dependencies that should be loaded by QuarkusClassLoader? If not, is there any plan to introduce such a mechanism?

No, the class loader used is more of an implementation detail and will be addressed by #43749 at some time in the future.

[reaver585]

@dmlloyd
Apologies for a late response.

The LogRecord (actually ExtLogRecord in Quarkus) does not render a log message. You still have direct access to every aspect of the log event and can render it however you wish.

The role of the Handler is to determine how log messages are processed (often by formatting the message to a file, but this is only one possibility). The Formatter is used for handlers which render a LogRecord into text (and only such handlers).

You should be able to do anything you need to by implementing one or the other of these, since no information is lost between the log method and the handler (unless the log message is filtered out by configuration).

You are absolutely correct. For some reason, I decided that SLF4j's processing of template strings, {}, is the culprit here, but that of course is not the case. Pardon the confusion, and thank you for your response.