Upgrading Logback Classic from 1.3.8 to 1.3.9 causes ClassNotFoundException: ch.qos.logback.classic.spi.Configurator

Hello everybody, this morning weekly build of our software breaks with java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.Configurator As we configure Gradle to apply runtimeOnly('ch.qos.logback:logback-classic:1.3+') this build receives new patch level version 1.3.9, published a few days ago. I've downloaded both versions, 1.3.8 and 1.3.9, of the lib from [1], missing class is available with 1.3.8, but missing in 1.3.9. General remark: I do not expect such a modification with patch level updates. My question: Is this a bug on your side, or have I missed some deprecation announcement explaining how to reconfigure Logback, or apply another Logback lib, or the like to avoid this problem? Thanks and regards Christian [1] https://mvnrepository.com/artifact/ch.qos.logback/logback-classic

Hi Christian, Thank you for bringing this issue to our attention. The class has been moved to logback-core module under ch.qos.logback.core.spi package by mistake during experimentation and will be reverted in the next version. Best regards, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 8/9/2023 8:44 AM, "Christian Möller via logback-user <logback-user@qo"@qos.ch wrote:
Hello everybody,
this morning weekly build of our software breaks with
java.lang.ClassNotFoundException: ch.qos.logback.classic.spi.Configurator
As we configure Gradle to apply
runtimeOnly('ch.qos.logback:logback-classic:1.3+')
this build receives new patch level version 1.3.9, published a few days ago.
I've downloaded both versions, 1.3.8 and 1.3.9, of the lib from [1], missing class is available with 1.3.8, but missing in 1.3.9.
General remark: I do not expect such a modification with patch level updates.
My question: Is this a bug on your side, or have I missed some deprecation announcement explaining how to reconfigure Logback, or apply another Logback lib, or the like to avoid this problem?
Thanks and regards
Christian
[1] https://mvnrepository.com/artifact/ch.qos.logback/logback-classic

Hi Ceki, thanks for your quick and helpful response. Regards Christian Am 09.08.23 um 11:17 schrieb Ceki Gülcü via logback-user:
Hi Christian,
Thank you for bringing this issue to our attention.
The class has been moved to logback-core module under ch.qos.logback.core.spi package by mistake during experimentation and will be reverted in the next version.
Best regards,

Hi Ceki, I've recognized arrival of two new versions 1.3.10 and 1.3.11 of your lib logback-classic. Unfortunately, both of them trigger following Exception with our application's test cases: java.lang.NoSuchMethodError: 'void ch.qos.logback.classic.util.ContextInitializer.configureByResource(java.net.URL)' at io.micronaut.logging.impl.LogbackUtils.configure(LogbackUtils.java:100) at io.micronaut.logging.impl.LogbackUtils.configure(LogbackUtils.java:57) at io.micronaut.management.endpoint.loggers.impl.LogbackLoggingSystem.refresh(LogbackLoggingSystem.java:134) [...] We are using Micronaut 3.9.4 in this project. Regards Christian Am 09.08.23 um 11:17 schrieb Ceki Gülcü via logback-user:
Hi Christian,
Thank you for bringing this issue to our attention.
The class has been moved to logback-core module under ch.qos.logback.core.spi package by mistake during experimentation and will be reverted in the next version.
Best regards,

Hi Christian, The deprecated method ContextInitializer.configureByResource was removed because it was preventing the decoupling of logback initialization from JoranConfigurator class. Downstream developers, for example Micronaut developers, can circumvent this incompatibility problem by copying the code in the ContextInitializer.configureByResource method into their project. This should be a relatively easy exercise. In any case, apologies for the inconvenience. Best regards, -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch On 8/11/2023 12:32 PM, "Christian Möller via logback-user <logback-user@qo"@qos.ch wrote:
Hi Ceki,
I've recognized arrival of two new versions 1.3.10 and 1.3.11 of your lib logback-classic.
Unfortunately, both of them trigger following Exception with our application's test cases:
java.lang.NoSuchMethodError: 'void ch.qos.logback.classic.util.ContextInitializer.configureByResource(java.net.URL)' at io.micronaut.logging.impl.LogbackUtils.configure(LogbackUtils.java:100) at io.micronaut.logging.impl.LogbackUtils.configure(LogbackUtils.java:57) at io.micronaut.management.endpoint.loggers.impl.LogbackLoggingSystem.refresh(LogbackLoggingSystem.java:134) [...]
We are using Micronaut 3.9.4 in this project.
Regards
Christian
Am 09.08.23 um 11:17 schrieb Ceki Gülcü via logback-user:
Hi Christian,
Thank you for bringing this issue to our attention.
The class has been moved to logback-core module under ch.qos.logback.core.spi package by mistake during experimentation and will be reverted in the next version.
Best regards,

Hi Ceki, back from vacation :-) So if I get it right, upgrading LogBack from 1.3.8 to 1.3.11 might break my code because of some refactorings you do on its code base, announced by a Deprecation-flag/-warning/-annotation. Hm, I personally would *not* expect such (occasionally client-breaking) modifications to appear with patch-level updates: Within version 1.4/5.x, I think that would be more appropriate. Let's hope that all upstream frameworks/users/etc. quickly adapt their codebase(s). In the meantime, my projects have to stay with 1.3.8. Just my two cents ... :-) Regards Christian Am 11.08.23 um 13:35 schrieb Ceki Gülcü via logback-user:
Hi Christian,
The deprecated method ContextInitializer.configureByResource was removed because it was preventing the decoupling of logback initialization from JoranConfigurator class.
Downstream developers, for example Micronaut developers, can circumvent this incompatibility problem by copying the code in the ContextInitializer.configureByResource method into their project. This should be a relatively easy exercise.
In any case, apologies for the inconvenience.
Best regards,
participants (2)
-
Ceki Gülcü
-
dcmoeller@gmx.de