Slf4j + logback

[seseso]

Describe the bug

First of all, I know that logback is not supported and JBoss Logging is the official logging framework. That being said, I manage to work with logback but found out that it only works in Profile prod and not in dev. I see a different behavior and that's why I open this issue.

The problem arise at:
ch.qos.logback.classic.LoggerContext lc = (ch.qos.logback.classic.LoggerContext) org.slf4j.LoggerFactory.getILoggerFactory();

which works in profile prod but throws a ClassCastException in profile dev:

ERROR: class org.slf4j.impl.Slf4jLoggerFactory cannot be cast to class ch.qos.logback.classic.LoggerContext (org.slf4j.impl.Slf4jLoggerFactory is in unnamed module of loader 'app'; ch.qos.logback.classic.LoggerContext is in unnamed module of loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @73c9e8e8)

Expected behavior

I would expect the same behavior in both profiles (even if that would mean a failure on both)

To Reproduce

https://github.com/seseso/quarkus-logback

mvn clean package -DskipTests
java -jar target/quarkus-app/quarkus-run.jar

Works as excpeted

mvn quarkus:dev

ERROR: class org.slf4j.impl.Slf4jLoggerFactory cannot be cast to class ch.qos.logback.classic.LoggerContext (org.slf4j.impl.Slf4jLoggerFactory is in unnamed module of loader 'app'; ch.qos.logback.classic.LoggerContext is in unnamed module of loader io.quarkus.bootstrap.classloading.QuarkusClassLoader @1a2b65ad)

Environment (please complete the following information):

Output of uname -a or ver

Linux hp-spectre-x360 5.8.0-44-generic #50-Ubuntu SMP Tue Feb 9 06:29:41 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Output of java -version

openjdk version "11.0.10" 2021-01-19
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.10+9)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.10+9, mixed mode)

GraalVM version (if different from Java)

N/A - Don't need to run in native mode

Quarkus version or git rev

1.12.2-Final

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

Apache Maven 3.6.3

[famod]

As much as I myself would also love to use logback, as you said yourself:

I know that logback is not supported and JBoss Logging is the official logging framework

I'm therefore going to convert this to an enhancement.

/cc @dmlloyd for general logging context and @stuartwdouglas for the classloading part

[dmlloyd]

A logging framework has four parts which are relevant to this discussion:

• The logging API (in the case of LogBack, this is slf4j; though Quarkus uses jboss-logging, slf4j is also completely supported for users)
• The logging implementation (this would be the "guts" of LogBack; Quarkus uses jboss-logmanager for this part, which is a substantially improved replacement core for the JDK's logging system)
• The logging configuration (Quarkus uses a unified configuration, so logging framework specific configuration file formats will not work here and probably never will; rather, we'd improve the logging configuration section of Quarkus configuration to support any missing use cases)
• The logging "accessories" like formatters, appenders, etc. (Quarkus already supports appenders from log4j and could readily support appenders from other frameworks as well).

So while on the one hand I can accurately state that "Quarkus does not, nor will it ever, support LogBack/log4j/etc. in place of its internal logging system", on the other hand doing so would completely miss the point that whatever you are trying to use LogBack for (and it's typically going to be for a particular appender or formatter), we either already support directly, could support directly, or could support via interfacing with LogBack at an SPI level like we do with log4j.

So, what is your particular use case for which you are trying to consume LogBack?

[dmlloyd]

As an aside: part of this is that we do need a good mechanism for detecting class path conflicts. This would be necessary before we can solve the "same error in both situations" part of the problem.

[seseso]

So, what is your particular use case for which you are trying to consume LogBack?

The only reason I use logback is to have access to the SiftingAppender, which I use to create logfiles "on demand", based on MDC properties. I need this to create separate log files per processing threads in a ETL pipeline. Other then that, I'll live happily without it!

[eriknyk]

same here,
I need to send logs to Loggly, it has its logback appender also and I'm not finding the way to make this working

https://documentation.solarwinds.com/en/Success_Center/loggly/Content/admin/java-logback.htm?cshid=loggly_java-logback.

I can see in quarkus logging docs, that it supports Sfj4j and exists and adapter for it, documented in the following url

https://quarkus.io/guides/logging#logging-adapters

However there is not any documentation to get Quarkus + Sfj4j + Logback + external appenders working.

Any help will be appreciated.

[loicmathieu]

@eriknyk Loggly can be used via rsyslog, and Quarkus has a syslog happen, see https://quarkus.io/guides/logging#syslog-log-handler

@seseso the issue with dev mode may be due to its classloader, can you try to register logback as a parent first dependency to see if it solves the issu? See https://quarkus.io/guides/class-loading-reference#parent-first-dependencies

[eriknyk]

Thanks @loicmathieu,
however rsyslog is not an options for us, and about parent-first-deps, we use gradle and not sure if is possible use quarkus-bootstrap-maven-plugin with gradle.

[dmlloyd]

So I guess the question comes down to:

• Should we implement an equivalent to the LogBack SiftingAppender?
• Should we provide a specific bridge to use LogBack's SiftingAppender?
• Should we examine the possibility of implementing a new file-based handler that has enough general capabilities to cover the requisite use cases?

/cc @jamezp for additional perspective.

[famod]

For me, something like TurboFilter (http://logback.qos.ch/manual/filters.html) would come in handy as well.

E.g. to suppress specific WARN and ERROR messages while doing negative tests.

[jamezp]

I can't find where this SiftingAppender lives in logback. That said it seems like a handler that could be created.

[jamezp]

For me, something like TurboFilter (http://logback.qos.ch/manual/filters.html) would come in handy as well.

E.g. to suppress specific WARN and ERROR messages while doing negative tests.

This sounds like a filter assigned to a logger instead of a handler.

[eriknyk]

Any Update about this?
I think that we should to be able to use Logback + external appenders transparectly (in my case I need to send logs to Loggly),
seems currently as it is, is limiting the real powerfull of logback what is not good.

Best Regards.

[survivant]

maybe you can check this extension
https://github.com/quarkiverse/quarkus-logging-logback